Thanks to Viv for having reproduced the schema for the reported bug I am working on since the last three weeks. It seems this is not related to .NET 1.1, but under the .NET 2.0 environment. IIS and VFPOleDb can still be part of the equation. While we can isolate the situation to a specific environment, no solution has been found yet on how to resolve the bug.
Today, what I did, was to implement a way to make this bug invisible to the Web site users. Basically, there is nothing we have found to avoid the bug but we can make it transparent to the user. Well, not technically, because the approach I used covers in fact about 95% of the situations only.
My data class handles SQL commands for SQLExec(), SQLUpdate(), SQLDelete() and SQLInsert(). The approach I use applies to SQLExec() only as it would be dangerous to apply that to the other three methods. The goal consists of retrying on failure. This is the approach I used for avoiding collisions when creating or reading a file. This approach has also been suggested by other members in the Universal Thread.
Basically, on SQLExec(), if it fails, I log the error under the terminology of "VFPOleDb.1 error: ..." which indicates me that this is an error that was reported on the SQLExec(). After the error is logged, the same loDataAdapter.DataFill() command is executed. On the 2nd try, it works. I was not able to simulate a problem when reexecuting the command twice. I put a maximum of 10 tries. The delay is .25 second.
When I run my test today, I sent 600 hits in two minutes. I sent the test against a production page which is one of the busiest of the site. That page processes about 25 SQL commands. Within that timeframe, I got 16 errors. All the errors reported were all related to that problem. But, on all those errors, the HTML code for the page was returned ok.
The following are in consideration:
1. This means that if I have a real error in my code, such as testing in development, that 10 errors would still be logged as the data class has no idea if this is a real bug or a bug in the data provider.
2. This does not resolve the issue. Microsoft still has to come up with a new release of the related component.
3. This only resolves 95% of the situations as the 5% are in regards to write methods and those cannot be encapsulated in such a business workaround decision to hide the bug from the user.
4. This is not a way to resolve the bug but only a workaround to diminish its visual effect to the user.
5. I will end up with a tons of error logs when there is in reality no error.
This issue is still in progress. I hope Microsoft will address the issue asap. This is of high priority for any developer using VFP as the backend. We have to remember that this does not apply, based on my prilimary tests, on the SQLClient provider. So, even if it does not happen under .NET 1.1 doesn't mean that this is .NET and IIS related only. Because, under .NET 2.0, IIS and SQLClient environment, I was not able to simulate the problem. But, under .NET 2.0, IIS and VFPOleDb environment, I am having it.
