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