At 09:32 AM 28-02-01 +1300, you wrote:

>Jason,
>
>that doesnt answer teh question. WHy does the table do that.... it does not
>make it compatible with TDataset. And If I knew I had to change all teh
>forms I wouldnt have switched over.

It sounds as if your problem is that you are in change-over from desktop database to client/server. They are chalk and cheese. If you want the same kind of speed in C/S that you had with desktop, you have a lot of rebuilding to do.

TIBOTable is there to emulate TTable.

TTable in C/S is a SELECT * FROM TABLE, i.e. it fetches all columns of all rows. It doesn't fetch all rows at once: it fetches until it fills the table's buffer. Then, any navigation beyond the group of rows already in the buffer will cause it to request more rows and swap out what it has. That's why, in C/s, you shouldn't use T..Table for anything but small lookup tables which you want to keep in memory.

TTable was designed for databases like Paradox and bTrieve, where your app is working directly with physical data files whose ordering, keying, etc. work with the physical format of the files. C/s is totally different. There is no table-like structure in the database at all and you never touch the database physically.

>We do have extensive search capability, but this is the way our clients liek
>things, they have for the last 15 years with DOS and CPM proggies.
>
>Since when does it become logical to change the app to suit the foibles of
>the tools ? :-)

It becomes not only logical but absolutely necessary when you shift from a file-served to a remote-server database. If your users want to use a table-driven application, keep bTrieve.

Cheers,
Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________