Hi John,

Another thing I like about perl is its DBI (e.g. Database independent connectivity) modules. The perl community provides the tool needed to connect to just about every database of which I know. The perl community is also very quick to adopt whenever there is any new innovations like XML, etc. I would be very surprised if anyone had something before the perl community.

DBI is becoming more important all the time because Microsoft has changed all the rule when it introduced OLE DB. This create major problems for guys like me, because I like to build VFP front end apps that interact with many different back ends like MS SQL, Visual FoxPro itself, MySQL, Postgresql, informix, sybase, DB@, etc. As new releases of Visual FoxPro, MSDE, Access, and MSSQL are released it become necessary to adopt OLE DB in order to have a sane/reliable connection from the front end Lapp.

However, once I write the app to be OLE DB specific, I'm look out of connecting to anything outside of the Microsoft universal as every other major Database engine is still using ODBC.

If I understand it correctly, OLE DB was built on top of ODBC at first, but has recently become native. With perl DBI I have the freedom to write against any back end database including MS SQL.

Jave also uses its own connectivity tool referred to as JDBC. Postgres has written an JDBC drive and supplies it along with its Postgresql back end engine free of charge. What a deal.

As near as I can tell, Microsoft adoption of OLE DB was purely a political move because it didn't provide any noticeable advantage over ODBC, other than to lock Microsoft products into MS SQL and to lock Microsoft Product out of using any other Database. RecordSet are nice, but could just as easily have been provided via ODBC. ODBC had ten years of improvement and was super fast and stable, so OLE DB really wasn't necessary other than to differentiate Microsoft Database for strategic purposes. Microsoft abandonments of support for ODBC has caused many no end of grief.

I heard Ed Leafe say the python has its own database drivers which are independent of ODBC and OLE DB. Can you verify.

Here is an email I saved that gives some idea of the my problems of Microsoft refusing to play nice with anyone outside its universe:

========================================================
The Subject of the email was titled:

ODBC 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



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

=============================================================

LelandJ