CD> A lot of the "extra capabilities" from ODBC flow from its design
 CD> goal of portability across as many DBMSs as possible.....
 NH> Does that mean that ONE ODBC driver could (theoretically) be used to
 NH> interrogate databases from several different vendors (Oracle, IBM, M$,
 NH> etc)?
 No, as I'm sure you know, the goal is the opposite: to be able to access
 different DBMSs using different ODBC drivers.
 The theory is that all you need to do is write one program to do your
 db stuff.  Then if you use a different backend, just use a different
 data source name that maps to the driver appropriate for the new db.
 This does work pretty well as long as what you are doing with the db
 is _extremely_simple_.  But even fairly simple stuff (like subqueries)
 that is standard SQL won't execute across popular micro db platforms.
 (Or at least won't execute properly with the ODBC drivers available
 for the db's.)
 Not only that, but some ways to access the db are excrutiatingly slow
 with one construct, but quite efficient with another.  (Part of this is
 a flaw in SQL design which allows a multiple of equivalent ways to
 do something rather than one way which can be consistently optimized.)
 One other problem is that there's often a lot you have to do with db's
 that isn't part of SQL.  One nice feature of ODBC is that you can
 access any vendor specific components you need.  But naturally vendor
 spedific stuff is vendor specific.
 So much like porting C code across platforms, "writing to the standard"
 is a very small piece (an insignificant piece?!?) of the work needed to
 port code to new databases.  Instead you have a lot of hard work testing
 all you program paths to make sure that stuf that's "supposed to work"
 really does work.
---
 þ Blue Wave/QWK v2.12 þ
---------------