>I can't say it's faster nor can I say it isn't supported (yet).

Ok, I misineterpreted the line where you said "It's very likely faster and uses less memory to go through ODBC". But, one thing for sure, it isn't supported yet as it has been tried and we get a message in regards to that.

>Case in point... several years ago I did some timing tests in VFP to access SQL Server. I used SQL Passthrough (ODBC), ADO (OLEDB), and cursor adapter (ODBC & ADO). Some things were faster with ODBC, some faster with OLEDB, some with SPT, some with CA. Bottom line, the speed depends on what you are doing. Of course it could be entirely different with non-SQL Server connections as they would use different ODBC drivers or OLEDB providers.

For that small application, the speed is not an issue as this is a single update on a single record that happens very rarely. My prime goal is to recommend an infrastructure that will not become obsolete soon and/or will not put us in a crisis situation, as so well mentioned.

That's why I am interested in the topic. Whenever OleDb is mentioned, with the experience I had with VFP, using OleDb data provider from .NET to access it, I have no problem moving it out of the loop. For that small application, I just found out it was still, well, the technology was still in use, in regards to OleDb, to access the DBase IV DBF file. So, if ODBC does at least the same thing, offers the same support and is not scheduled for discountinuaton, I would vote for it.