>>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....
>
>So, basically, what setup do you recommend?
>
>Also, do you find this acceptable that I have to issue an application lock 160 times per second, assuming I have 4 hits per second on a specific transaction?
>
>Can you include the SQL you used for your tests in here? I have found that it was difficult to obtain an error with the application lock approach with a simple SQL. But, as soon as I put in the production SQL, where there are a lot of INNER JOINs with several fields, I started to get those again.

The SQL was a *very* basic 'SELECT.....' no updates, no joins etc. As mentioned above I think the *only* safe solution is to apply the Application.Lock() before opening the connection and to keep it in place until the connection is closed. Given the overhead of implementing the lock it may well be that overall performance is as good as, if not better, than wrapping each SQL execution in its own lock. And upping the process count in the application pool seems to improve performance.

In my test running the 'safe' solution reduced the number of hits handled by about 15% - hopefully your server would have enough 'headroom' to make that acceptable.

Best,
Viv