Re: Multi Tiered ODBC

In previous posts <many> discussed ODBC: points made: 1. Microsoft sactioned ODBC "tier" definition is the common sense client/server "tier" + 1. (I agree.) 2. There are flat file ODBC drivers (Text file, dBase, etc.), RDBMS ODBC drivers, and server side drivers. (I agree.) 3. ODBC is very useful in getting information (report) out of legacy systems and small databases. (I agree.) 4. The gap in functionality and performance between ODBC drivers and native APIs is narrowing. (I agree.) 5. ODBC is the future, proprietary API is doomed. (I agree to some extent.) I can see why people feel enthiusiastic about ODBC. ODBC opened a lot of doors. Things can now be done that's unthinkable five years ago. Do I feel the power when I can join a table on an Oracle server in LA and another table on a SQLServer in DC, right here on my PC in Chicago? Of cause. Can I rely on it to have my time-critical/"mission-critical" job done? I'd think twice!!! It all come back to that one saying "for everything, there is a time". ODBC is designed to be an abstract layer on top of proprietary RDBMS (and other methods) APIs, so that a Windows application (e.g. Excel) vendor "don't have to recompile their executable for each different database system". And it is better that we think of it and use it that way. Proprietary database access APIs for Windows are usualy designed to give the Windows application developer optimized access to one particular RDBMS system, taking advantage of any unique features that no one else offers. And it is better that we think of it and use it that way. Until the day comes when the now generation "Our proprietary API is ODBC-We don't have the burden of history-We don't do any proprietary extentions-Our SQL is exactly ANSI SQL" database management systems have accumulated enough experience and achieved the status of the current market leaders, there is always room for the proprietary API to live. However, by then, maybe, just maybe, ODBC itself will be history. -- Weiqi Gao weiqigao@crl.com