Re: FUD!! ODBC will not be supported by Microsoft 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