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