Hi Simon,
Unless Microsoft can be presuaded to continue supporting back ends other than MSDE, MS SQL, Access, VFP, etc, it may be necessary to use OLE DB to connect to Microsoft Products only. Not only that, it might require a re-write of existing VFP apps based on cursor over ODBC, so they worked with recordset instead. You might also check for third party VFP ODBC providers.
There really doesn't seem to be many choices.
You might ask Ken Levy this question. It would be wounderful if the VFP team were allowed to write an ODBC Driver that not only continued to support current app, but also supported all other back end that are standardized on ODBC. I've also had problems accessing VFP DBC over ODBC using non Microsoft tools like perl because the ODBC does not support new stuff like like triggers which are necessary for VFP referential integrity and the new VFP auto-increment of primary keys fails. Here is an email that gives further hints about the problem.
=======================================================
The subject of this email was titled:
ODBC FUD!! ODBC will not be supported by Microsft in the future
Hi, Relaxin wrote...
This is my last post for this topic since it is now offtopic
--Sorry to inform you, but ODBC is NOT SQL Server's native connectivity, it's
--OLEDB.
First of all Microsoft Query Analyzer seems to use ODBC. Microsoft rather
uses ODBC itself then OLE/DB for this app. BUT promotes others to use OLE/DB
(by dropping OLE/DB /-/ ODBC interconnectivity).
"Native connectivity" is whatever connectivity the database vendor chooses
to implement (--/ TDS!, Net8, whatever). We don't have to care about this.
ODBC uses a driver concept as an abstraction from this concept. This is the
industry standard. I haven't seen that many native OLE-DB drivers.
Dropping OLEDB/ODBC connectivity means people using OLE as their lowest DB
API will have to use databases that provide native whatever OLEDB Access.
Which of course is a risk, because ODBC drivers are still used primarily in
the industry and are already well tested. But these guys will have to port
their VB6 apps to VB.NET anyway, their ASP things to the totally different
ASP.NET, etc and use C# anyway, until the next technology iteration arrives.
--need high performance. The OLE DB Provider for SQL Server (SQLOLEDB) is a
--native, high performance provider that accesses the SQL Server TDS protocol
--directly".
Yeah, the ODBC driver probably uses TDS aswell. "High Performance." Now if
you can do C++ take the otl template library, use an fast Ora9i server and
write some database code using a) "more native" Oracle 9i OCI and b) the
Oracle ODBC Driver (MS or Ora). You can switch using a single #define. Then
realize how fast odbc really is.
--connect to it will be to write native calls to ODBC. You would be stupid
to
--write a new application to talk natively to ODBC, since MS will not be
--making any new enhancements or fixes to ODBC, MS is dropping the OLEDB to
--ODBC bridge and OLEDB and ADO.Net are where things are headed (and has been
--for a couple of years now).
Of course you need support for any technology - this is a political move.
There are no direct technical reasons for do so.
Microsoft marks ODBC as deprecated? Ok, the ODBC Implementation from
Microsoft is very good but the specs are clear - writing a free odbc
implementation (based on unixodbc) is an adequate challenge for the open
source community.
--It will be you and your customer that will suffer, not me. All of my
--applications that I write go thru OLEDB.
My databases are rather big (geneome databases, medical directories with
about 20mio entries) and I basically do a lot of OLAP. There is no way
around ODBC. Try to use Data mining tool SPSS Clementine to connect to a
database using OLE DB. No way.
--Plus, Postgresql's ODBC has some serious problems, I wouldn't trust in
--production on Windows anyhow.
The ODBC architecture has established itself, it is over 10 years old, solid
and industry standard. Every important datbase vendor has an ODBC Driver.
Find me an OLE-DB or whatever .NET provider for every significant database
out there.
Issues with a specific driver (in this case: odbc) are issues with a
specific driver and not issues with an architecture.
--Thanks
You're welcome.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 29.09.2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 29.09.2003
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
================================================================
Regards,
LelandJ
