>2) When using vfp in connection with IIS like West-Wind or ActiveVfp they usually go for COM-servers in native mode, not via OLEDB. Is your desktop app running a) in several parallel processes on the same machine and b) querying via OLEDB ?

The desktop application are single process querying via OLEDB.

>3) You could create some vfp-activeX-dataservers which do nothing but run a sql given as parameter via makroexpansion and return the result as XML, thus eliminating OLEDB. This is definitely NOT a technological reccommandation, more like a last resort while you wait for MS to fix the trouble with the OLEDB/iis/.net combo. Probably quite easier to implement into your existing application than switching to SQL server wholesale, giving you a solution NOW workable but less scalable and quite a hack <g>.

This is what I started to work on yesterday. I didn't want to use that route because it has slowed down the application by three times. It also adds additional layers or support and such. But, I did test that by the use of calling a Web Service for such need. My first test was to use a Web Service in the same environment, thus .NET and OleDb. That was bound to the same result. The second test in regards to that that could be something about it would be as you said, and also as requested by some others, to add an additional layer which would be VFP's own. But, this would cause me a lot of work because I would have to simulate the same data class I have in my framework and that is huge because it does a lot of things.

In the next hours, I am testing an approach to get rid of 98% of the errors by requering the SQL, for SQLExec() only, which represent about 95% of our SQL commands.