>
Thanks for the perspective. In this case, SELECT * doesn't bother me because they are lookup tables with no more than 20 rows apiece and no more than 3 columns per table.
>

OK...


>
Here's the situation: I have no control over the SPs of the database because I have been flat out told that the DBA will not allow new SPs.
<

Yet he/she will allow client-side rendered SQL Selects.... At least with an SP, they have control over what is happening. In a word,the DBA is an idiot.

<<
I have an incoming ASCII file. The file has about 10 foreign keys per row that may or may not be valid so I have to lookup each one of them. I expect no more than 200 rows.

When running this in a loop with .Open("SELECT * FROM table WHERE pk = &cFK"), the application is bogging down tremendously. This is why I was thinking of using the .Open("SELECT * FROM table") before beginning the loop and then using .FIND("pk = &cFK"). Would the reduced IO be faster?

<<

Well, I still don't have a good handle on what it is you are doing - a straight query or the updating of data... In any case, the approach here sucks. Nothing personal as I can see you are being hamstrung by that - yes I will say it again - IDIOT DBA.

Why not ask the DBA if you can have your own application specific database on that server - or perhaps on a different server. Then, you could have SP's on your database that point to the tables on the production database.

Looping through records in ADO is not the fastest game in town. And, if all you are doing is fetching records, it all should be prepared and executed on the server anyway.

I suppose fetching the records ahead of time and doing everything locally would be faster. Then again, why not use SPT and forget ADO? Are you doing this in Fox?? If so, SPT might be the better way...