>>Hmmmm, as long as the errors are always "showstoppers" generating real errors and not silently giving false info back, you could always loop until a query returns error free. I used a similar approach a few years back when every umpteenth "use" failed to set the specified alias - usually after a couple of heavy datacrunching hours. This was still in vfp6 without try-catch available, so based on the frequencies you cited I'ld loop the query until a dozen errors were reached in a row without a working call - that would probably some truly erroneos SQL - and your code heals the buggy OLEDB for you. Do the math: if you are incurring the an error every hundred calls, you can run a few millenia without incurring 12 such errors in a row from an otherwise "clean" SQL even on traffic much higher tan your estimates. Performance should not really be hurt, as try should be fast and only the catch incurs a meassurable lag, so the whole thing should be at less than 1.5% performance loss for 1% of
>>errors ocurring on the calls <g>.
>
>Yes, I thought about that. The idea is good. However, this is extremely dangerous.

Momentarily you are trying to find a way with the least negative consequences.

> This is happening on SQL Exec, update, insert and delete. So, in the case someone purchases something in the store, this could result in disastrous effect if I would try catch that in a lopp and reissue the command. This can produce unexpected results. And, for most of them, I could even say unwanted results. In a regular SQL Exec command, this could work. But again, it could be difficult to isolate the SQL command that is ok versus the one that could be really buggy which would need some fix. But, as most of them are occuring in SQL Exec, a try catch in a loop could apply as this would bring down the occurence of the other type of SQLs into a ratio of 1/10 approximately. But, I would have to look more into it. There would be a lot of considerations to analyze first.

I have no idea how much performance leeway you currently have. Adding transactions into a situation already partly broken (as compared to "fragile" only) in itself is a risk, but you might consider implementing a test mode with different transaction levels, writing out the data 2, 3 or 4 times in a row and getting an estimation of correct value back (which is error-prone in itself <g>) before always backrolling. YOu leave the loop and the first level of transaction only after everything seems ok. After adding logging the various errors you'ld get a pretty exact picture of the distribution of hard and soft errors occurring.

Running such a mode during the start-up phase of the app might be possible on your nice HW. But if the *percentage* of errors rises with the amount of traffic you will have a solid barrier in your scalability.

regards

thomas