Hey Kevin. As Jon mentioned, VFP is simply quicker for database access than anything else (at least that I have used). So, to some degree, there's not much you can do.

Having said that, the whole approach to data in .NET (or VB-classic or C++) is so different that in VFP, that you may need to re-think your approaches. VB is slower processing data than VFP under just about any circumstances, but it's at its worst when you "think-VFP" but "Code-VB."

For instance, I frequently grab a whole lot of data in VFP (frequently a whole table) and scan through it, taking various actions. Scanning through an ADO recordset is sooooo much slower than scanning through a VFP table or cursor, with large recordsets, that everything will grind to a halt. However, if you step back and consider off-loading some of the scan-processing to the initial SQL query, you could gain back some of the speed....

This is just one example, and I could provide lots of others. While the various VFP/VB translation charts that I have seen have helped ease the way to new syntax rules for legions of VFP developers, I fear that thinking about language comparisons word-by-word misses an important part of switching to a new language: knowing its strengths and weaknesses.

So, while some loss of performance is inevitable, be careful not to make it even worse by "thinking VFP" while coding in a different language.

>>>Like I said, I can understand WHY it has to be this way, but I do feel cheated having being made available to some brilliant DB commands in fox, only to have to be brought back down to reality with a different product.
>>
>>Kevin,
>>
>>VFP has a native database engine, VB does not. Simple as that. So it's not truly an apples-to-apples comparison.
>
>Yes, I understand that, and if that's the case, maybe Visual Studio .Net shouldnt' be marked as being brilliant for DB apps, when it clearly isn't in terms of performance. I know it will improve over time, but never to the standard VFPers are used to.
>
>>
>>Just out of curiosity, have you tried the same operations in VB.NET using the ODBC driver instead of the VFP OLEDB provider? It might perform quicker.
>
>No, I haven't tried it, I was under the impression the OLE DB provider is quicker.
>
>Kev