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

You might look up the Advantage drivers - AFAIR available in 64 bit size now for a couple of years and supporting vfp down to binary index. Dunno about their dB4 support - but for dB4 data either google specifically or visit their support groups - perhaps a task for those responsible for those deciding on dB4 format and keeping it in there ;-)

HTH

thomas