Thread: Re: FUD!! ODBC will not be supported by Microsoft in the future

Hi,
this might be actually offtopic, but its always time to fight FUD  :-)

> Microsoft will be doing away with the OLEDB to ODBC bridge in the near
> future.

Funny enough if I use __Microsoft__ SQL Query Analyzer which directly
connects to SQL Servers and somehow shut the SQL Server down while a query
running
I get the following message (german):
_________________________________________________________
Server: Nachr.-Nr. 17, Schweregrad 16, Status 1, Zeile 0
[Microsoft][ODBC SQL Server Driver][Shared Memory]SQL Server existiert nicht
oder Zugriff verweigert.
Server: Nachr.-Nr. 2, Schweregrad 16, Status 1, Zeile 0
[Microsoft][ODBC SQL Server Driver][Shared Memory]ConnectionOpen
(Connect()).
_________________________________________________________

Which means Microsoft uses ODBC itself for its internal DB Access with SQL
Query Analyzer, and NOT OLE DB.

Now if they can use this for their native DB Access, it must be perfect for
me.

Nice try anyway.

--
NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse für Mail, Message, More! +++

Relaxin wrote:

<snip>
>
> Plus, Postgresql's ODBC has some serious problems, I wouldn't trust in
> production on Windows anyhow. :)
>
> Thanks

That's a red herring.  Can you be more specific?  I've not seen trouble with
PG ODBC, but I'm not beating on it yet with any great force...

John.

>
> Which means Microsoft uses ODBC itself for its internal DB Access with SQL
> Query Analyzer, and NOT OLE DB.
>
> Now if they can use this for their native DB Access, it must be perfect
for
> me.
>
> Nice try anyway.
>

Sorry to inform you, but ODBC is NOT SQL Server's native connectivity, it's
OLEDB.

"OLE DB is a low-level, COM API that is used for accessing data. OLE DB is
recommended for developing tools, utilities, or low-level components that
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".

This statement is from the "OLEDB and SQL Server" manual that comes with the
Platform SDK (oledbsql.chm).


It's totally up to you to disregard what MS has said is coming, but the
people that live thru the problem when MS dropped MS Jet Engine and Foxpro
connectivity understand the significants of this statement.

Without a native OLEDB connectivity solution, if your customers are on a
version of MDAC that no longer supports your way of connecting to the
database...you have some big problems on your hand.

Sure, ODBC will still be around, but the only way you will be able to
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).

When the OLEDB 2 ODBC bridge is dropped, Query Analyzer will be updated,
just like Access was modified to support SQL Server (and Access, but thru
native calls to the Jet Engine)  when MS dropped the Jet Engine support in
MDAC.

It will be you and your customer that will suffer, not me.  All of my
applications that I write go thru OLEDB.

Plus, Postgresql's ODBC has some serious problems, I wouldn't trust in
production on Windows anyhow. :)

Thanks

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