>>A SWAG - maybe you could try installing Visual Studio + SPs on one of the servers (just install it, don't actually use it), so you have the same environment there as on your dev box.
>
>When I ran more tests on the development PC, I was able to simulate the same situation. It is just that it takes more time as this is not the same power as the servers.

Another SWAG - did you ever try using VFPOLEDB from .Net 1.1? Did you have any errors on that platform? If not, maybe there's an obscure new setting in 2.0 that needs to be set for VFPOLEDB to work properly. Or, maybe there are performance optimizations in 2.0 that break it.

>
>>If that makes a difference, look very closely at file/.DLL versions on the servers vs. those on your dev machine.
>>
>>Another SWAG - is there any difference in the AV products used on the various machines?
>
>On the development PC, we have McAfee Online Virus Scan and the server version on the servers.
>
>Last night, I started to migrate to SQL Server a portion of the components. I ran a big test for 20 minutes. I did it twice. The SQLClient provider is answering about 3 times faster than the VFP OleDb provider. So, I was able to send three times more hits than the previous tests. I didn't have one single error. This was working extremely fast without any error at all.
>
>But, I need to migrate fully and send the full set of tests as soon as I will be able to. But, this seems to be exactly as I saw it at first. The VFP OleDb provider doesn't seem to be in the game.

I guess to really nail down the VFPOLEDB issues you'd have to send your entire test suite to someone else, either MS or elsewhere. Since you're an MVP maybe MS would listen. But it might be tough for them to duplicate unless your environment runs on something like Virtual Server VMs.

If SQL Server Express performs better than VFPOLEDB and has similar capacity and scaling limits, maybe that is the way to go.