>I have very similar troubles. Generally I have found that SQL select's are not as fast as direct seek's and all the rest of the support code that would be required to match the SQL select. In fact we have used a network monitor to check why the above statement is true. We discovered that the entire index was being transfered to the workstation from the server (even if we asked for only the first 100 records via record selection). Since our indexes were very large on one of the tables it took forever. But we were able to improve performance using cache and improving the network hardware.
>
>But our real trouble has been using tableupdate. It can take well over two minutes to update the table.
>
>So what we have done is to continue to use SQL where performance is reasonable and where it is not - we are using old 2.6 type code to get the job done. The 2.6 code is like night and day in terms of performance.
>
>Many of the UT people were very helpful - most of them suggested changing indexes etc. But their suggestions did not solve our problem of performance. (mostly the tableupdate) So in the end we went with the old type code.
>
>Our total data is about 6 Gigs now. The index in question is about 125 Megs. Most of the data is normalized (which maybe the wrong way to go). And the form in question used tables that were indexed on jobid (a primary key). In the end the tableupdate went from 2 mintues to nothing.
>
>John
John,
Thanks for your information. So far adding a CUSTID Tag to the index in FP 2.6 and adding and relating the tables directly in the DataEnvironment of my form has performed well. Of course the largest index I have is only 10 meg and I am developing in an NT Network environment where the server has an IDE drive and 64 meg RAM. But the final product will be in an NT Environment with a SCSI drive and 192 meg RAM. Hope that will give an additional performance jump. I'm still in the very early stages of this project. I may try the SEEKs you mentioned, as this app will be for data extraction only......for now.
Thanks
Elgin
