The Historic's file format is not appropriate for playback, because normally many duplicated data is stored. Playback queries have an extra work to eliminate duplicated data from each Tag and find out only value-changing events, which may demand long sequential queries on a Historic table. It is recommended to use a Storage whenever possible. If Historic data is indispensable on playback, users must follow these recommendations:

•Configure the UserTable property to False (if this property remains in True, the _Fields table of this Historic is not generated, and this Historic is not recognized by playback)

•Place each Tag on a separate field (do not use expressions on field's source, for example)

•Create an index for the E3TimeStamp field. Without this index, Historic queries get slow, turning playback impracticable

•Use tables with a few fields and, if possible, add an individual index for each field (mainly for fields with little variation)

•Configure the CompressedTable property to True and use the DeadBand property on this Historic

The next figure shows how to configure an index for the E3TimeStamp field.

Defining an index for the E3TimeStamp field