Here is the next chapter of this adventure.
The bug report has been filled on October 3rd. When crossposting topics with Sasha, from the Microsoft MVP program, this one came on the subject. I mentioned him that we have been wasted a lot of times trying to resolve and/or find a workaround to the VFPOleDb provider bug. When doing a very short resume of the situation, it was mentioned that no feedback was provided so far. Yesterday afternoon, he suggested he would try to help on the issue by helping on its escalation. It didn't take long. Three hours and three minutes later, I got a response from Microsoft with an email which contains, among other things, this line:
"Thank you for reporting this. Can you try this after executing SET REPROCESS TO 50 or above? The default is 5, and we have seen issues with that."
Well, first of all, thanks to Sasha. Sometimes, we need little help like that, or should I correct that and say "big help" to help escalating important issues to a higher level so we can get a status on what is going on. As mentioned, the bug has been filled on October 3rd and nothing was checked on it for 10 days.
Secondly, what I received is not related at all to the issue, IMHO, and based on my perception of what SET REPROCESS does. The goal here is not to resolve an issue in trying to reprocess a command. Because, the command does execute. It is just that when it executes, sometimes, it completely looses itself in a black hole and returns various error messages totally not related. IAC, I tried to reply to them and the email bounced. So, I decided to go online and try to post a comment. Under my account, I cannot post a comment anymore. But, FWIW, I did try that suggestion. Without any surprise, it doesn't change anything. But, I did try it because it was suggested by Microsoft and because I figured that maybe they know something I don't behind this SET REPROCESS command. The number of errors generated from the stress test was exactly on the same ratio.
Again, for those who wish to get the overall view of this topic, the link is here:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=217718As for the change I did in the code, it is working well so far. I get about 4 to 10 errors a day (not real errors for those new to this thread) and because of the design which consists of reissuing the same command when this is happening, this makes it ok on the 2nd try. So, the user doesn't know anything about the error. But, this doesn't do anything good for SQLUpdate(), SQLDelete() and SQLInsert() as those methods are writing data and we cannot apply such logic as a workaround to hide the bug visually to the user, despite the fact that it is logged into the error table.
Again, this situation has been simulated in a totally different environment than mine (thanks to Viv) and it applies to .NET 2.0 with the VFPOleDb data provider.
