Hi John,

>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.

You said it, I didn't :-)

><<
>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.

Straight query. Validating the foreign keys in an ASCII file. Updating comes later and that's not a problem.

>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.

Hah. Hah haha. HAHAHAHAhahahah.....ROFLMAO. The DBA would likely call me a seditionist if I even suggested something like that. Great idea, though.

>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...

I am replacing an application that did it via SPT. And it worked. And worked WELL. Get this: The client has ADO as a "standard" for all internal data access and this is the reason I was hired in the first place.