Click above to get retro games delivered to your door ever month!

   Unpredictable Results with TPS
------------------------------------------------------------------------------

   Non-Advantage Applications Sharing Common Data

   The Advantage TPS is only supported when Advantage Locking is being
   used (i.e. AXS LOCKING is ON). This is to ensure that the Advantage
   Database Server maintains full file access and locking control. All
   applications accessing the same data should be integrated with
   Advantage to ensure full data integrity.

   If non-Advantage applications access this shared data, unpredictable
   results may occur. The "deleted" byte is used by the Advantage TPS to
   note the status of records within a transaction. A varied value could
   cause non-Advantage applications trouble in determining record deletion
   status. To avoid this problem, a one byte character field with the name
   AXS_TPS can be added to your tables. If this field exists, the
   Advantage TPS will use it to track record status rather than the
   "deleted" byte. Also, while a record is being updated during a
   transaction, there can be multiple index keys referencing a single
   record. If a non-Advantage application is accessing the data, it could
   use the wrong index key for the record(s) in question or see the index
   as corrupt.

   SUM, COUNT, AVERAGE with Advantage Optimized Filters

   SUM, COUNT, and AVERAGE may provide unpredictable results if used with
   Advantage Optimized Filters. While a record is being updated during a
   transaction, there may be multiple index keys referencing a single record.
   Advantage Optimized Filters use an index rather than the table to
   determine results of queries.

   SUM, COUNT, and AVERAGE with Advantage Optimized Filters may produce
   erroneous results due to the extra keys that temporarily exist in the
   index. If these commands must be used during an application, use them
   without Advantage Optimized Filters, when no other users are within a
   transaction, or with exclusive use or a file lock on the table.

   Unique Indexes

   Unique index updates during a transaction may not work perfectly with
   the Advantage TPS. However, similar undesirable update behavior can
   also result with CA-Clipper.

   For an example of undesirable update behavior with unique indexes that
   exists with both CA-Clipper and Advantage TPS, assume "Smith" is a
   non-unique last name located in record 69. Also, assume "Smith" is a
   key in a unique index, which references record 69. If "Smith" is
   changed to "Jones", then that index will no longer have any reference
   to a "Smith", although the last name "Smith" may still exist in the
   table.

   There is one specific case, however, where a unique index update with
   Advantage TPS does not work the same as it does with CA-Clipper.
   Following the same example above, if during a transaction "Smith" is
   changed to "Jones" in record 69, then "Anderson" is changed to "Smith"
   in record 70, there will not be any reference to a "Smith" in the
   unique index when a COMMIT TRANSACTION has completed. With CA-Clipper,
   the "Smith" (now in record 70) would exist in the unique index.