Hi,

>>What was the suggested workaround ?
>
>

>Application.Lock()
>oDataAdapter.Fill(oDataSet)
>Application.UnLock()
>

>
>You will see that instead of having several errors per seconds, you will get only several errors per minutes. The environment for the testing that person used was not having an intensive SQL command. If you test it with about 10 tables as far as the INNER JOIN goes within the same SQL with a lot of fields, this does not resolve the issue.
>
>When using that, he mentioned that this would limit the scalability. He found that one can improve the scalability to a great extent by configuring the IIS6 Application Pool, Performance tab property "Maximum number of worker processes" to a number greater than the default of 1, to something between 3 and 6.
>
>But, still, having to lock the application 40 times in one hit and about 160 times per seconds, assuming 4 hits a second, is, of course, a workaround that wouldn't make sense for me to use.


I thought we'd tried this. Anyway I revisited and below are my results:

                                  Hits    Fails
In IIS Isolation Mode
Full Lock                         6280     0
DataSet Lock                      7645     38
No Lock                           7677     63

Application Pool 1 Process
Full Lock                         5531     0
DataSet Lock                      7827     63
No Lock                           7396     53

Application Pool 6 Processes
Full Lock                         6167     0
Dataset Lock                      6801     5
No Lock                           6922     2

'DataSet Lock' is when just the call to 'FillDataSet' is locked (as per the suggestion). For 'Full Lock' the lock was in force from before the connection was opened until it closed. Although a one off run may not be statistically significant it's interesting to note that using the application pool I got more errors with the DataSet lock than with no lock at all - so not much advantage there!

The above was using a 1 minute test with 20 threads.
All in all the only safe solution seems to be applying a lock for the duration of the VFPOLEDB connection (and improving performance by upping the application pool process count).

If you're seeing a larger improvement than me by just locking around the FillDataSet() then this can probably be attributed to the relatively longer SQL execution time - meaning that a larger percentage of the time that the connection is open is protected by the lock....

Best,
Viv