Re: 8.1.6 on windows 2000, no odbc?

"Galen Boyer" <galenboyer_at_hotpop.com> wrote

> > but then neither is ODBC a bright idea either.
>
> This is the one serious thought I have in my post. Why do you say
> this? ODBC certainly has been used successfully by many client
> apps. Maybe because its from MS, that none of us really want to
> like it, but I don't understand how it isn't a "bright" idea.

My Problems with ODBC.
A Trilogy In One Part.

It was a cold, dark and stormy night...

1. Many ODBC drivers messes around with your SQL in an attempt to perform local verification. Yeah, the ODBC_PASSTHROUGH parameter takes care of this, usually, but how many heads have been butted against so-called intelligent ODBC drivers? It also begs the question WHY ON EARTH you need to have a PASSTHRU parameter in the first place.
2. Network performance. New/modern ODBC drivers do allow better network performance tuning. But that did not helped me back in the 90's. Not when we benchmarked ODBC drivers which were up to 100% times SLOWER than a native connection and caused a lot more network traffic.
3. Inconsistency. Not all ODBC are created equal.
4. Which leads to the next point. As you get more than ODBC driver from different vendors for the same native db library, which one do you use? Time wasted on trial and error trying to discover that. Including running sniffer tests to see what the ODBC drivers do to the network.
5. Installation problems.
6. Support problems. Especially when users starts installing new drivers himself. Or change from one vendor drive to another.
7. Application performance and complexity problems. Adding ODBC means adding another layer below the application. This impacts on both performance and complexity.

I'm sure I can dig up some more arguments, after I had some more coffee. :-)

Is ODBC bad? No. It is conceptually a good idea to abstract the native db library interface in such a way that it provides 1 - an easy interface to an often complex API 2 - provides you with the means of being db library independent

The next question that people need to ask is WHY do they want to use ODBC. The answers are usually pretty much numbers 1 and 2 I gave above. However, it is often UNTRUE.

If you are a Oracle shop, why use ODBC drivers to provide you with a means of hooking your applications into DB2, Informix, SQL-Server, Sybase or whatever?

If you have a database strategy in place, it is highly unlikely it will change. Huge amounts of investment go into it. So saying that you need to use ODBC as it allows your apps to be used against another database, in case the company one day changes its database strategy, is simply ridiculous.

Easy interface to something like OCI? Yes, but at what cost when looking at the cons. Especially at performance, installation and support issues. There are better methods. In fact, new Enterprise development tools like Delphi 6, supports NATIVE connectivity to databases like Oracle. So you do not need ODBC or even Borland's BDE.

If you look around on the net, you will find some _excellent+ C++ OCI classes (freeware/opensource) which can be used instead of ODBC or Pro*C.

My problem with ODBC is in fact more a problem with why people use ODBC. So often I see a technology being used, without first thinking through the WHY. People tend to grab the first tool at hand to fix things. Which is seldom the best tool. Which explains why ODBC is so popular. If you only use a hammer, all problems start looking like nails.

--
Billy