>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. 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.