Quote from kkmfg on 09/09/07 at 08:38:44:When you use ODBC you are just using the relational engine to access the btrieve data. I would highly doubt that adding an index in ODBC could be possible if it did not also add the index in the btrieve files. An index, after all, should be stored on disk if it's to do any good. Why would PervasiveSQL create an index only for ODBC? My guess is that you can add indices to a btrieve table but that the original program won't necessarily use the index.
Yes, That is true. The index is embedded in the table (unless you create an Index only file). I do not believe that the
TAS applications will not use it because they are not written to access any invoice data by date. In programs that allow
you to specify an invoice date, the program logic will compare dates of records returned and ignore any that do not fall in the specified range.
This is an example of some of the old junk code that ISTECH support has to deal with. Works great on the Demo data that has 12 records in the
file, but is not practical for real datasets.
My concern was regarding the ODBCDDF.RUN program that creates the ODBC compatible DDF files.
If it is not modified, then when it creates the INDEX.DDF file, it will not include the definition for any new indexes that have been
created (and embedded) in the tables.
Now, having said that, it is only necessary to run ODBCDDF.RUN when there is a change to the table definition. This does not happen
very often. It would be nice if I did not lose the newly created index when it becomes necessary to run ODBCDDF.RUN in the future.