>
>I think it depends on what You want to return. You can't for instance return a cursor from a COM-Server, nor a DataSet as VFP does not know DS's (I didn't try, but I guess that's the way it is.) You could return an ADO-Recordset but that wouldn't be an ADO.NET Recordset. on the other side XML will be no problem.
>

It would be great if VFP SP could return a dataset to ASP.NET. I was hoping that VFP 9 would have this feature, but ...

>I'd say, as long as You simply need plain data OLEDB will do well, despite things with a complicated Business-logic are probably better handled via COM (something like "SaveCustomerRecord()") where things are better encapsulated. Though You can do a lot via the stored Procedures.
>

So far I found that I can do pretty much anything I need, as far as business logic in a SP. I think that the downside of COM is if you have a problem, you have to unload bad COM and load a new one. Whereas when you do it on a web server with many other applications running, it might have some side effect (I don't know for the fact, just speculating). SP is easy, just xcopy new one and all done.

>It somehow leads to the philosophic question "Where does the Business-logic belong to". If You keep it in the StoredProcedures, it's tight to VFP, as You'd have to rewrite it when moving to another Database. Others say it belongs to the DATA.