Re: FUD!! ODBC will not be supported by Microsoft in the future - Mailing list pgsql-odbc
From | Amanjit Gill |
---|---|
Subject | Re: FUD!! ODBC will not be supported by Microsoft in the future |
Date | |
Msg-id | 001301c389a8$b5dac3f0$0400a8c0@charite.de Whole thread Raw |
In response to | Re: FUD!! ODBC will not be supported by Microsoft in the future ("Relaxin" <noname@spam.com>) |
List | pgsql-odbc |
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
pgsql-odbc by date: