transactions and MS SQL Server 7.0

[Alex Martelli]

<jeffcjohnson at my-deja.com> wrote in message
news:8m9853$oa2$1 at nnrp1.deja.com...
> Thanks for the info, I'll look into ADO.  I also downloaded mxODBC but
> haven't installed it yet.  Are there pros and cons for each?  ADO makes
> me nervous because it sounds proprietary and who knows when I'll have
> to switch to Sybase or whatever.  I'd prefer to stick to open standards
> unless there is a good reason not to..

ADO is a 'proprietary standard' (yeah, I know, we do oxymorons by the
dozen:-) just like good old ODBC is/was.  The ADO layer provides ease
of programming (particularly for the user of scripting languages) and it
rests upon 'OLE/Db', which is a lower-level interface set.  Anybody can
release OLE/Db providers for whatever data-sources, and ADO-using
programs will be able to communicate with the data-sources.

For example, 'Attunity Connect' (what a name...!-), a UK firm, claim:
"Attunity Connect offers open interfaces such as XML, ADO/OLE DB,
ODBC, and JDBC for client applications" and support Sybase among
other databases (http://www.isg.co.uk/),

Merant, a US firm (http://www.merant.com/) supply the "Merant
DataDirect" products, including "DataDirect Connect ADO" which
supports Informix, Microsoft, Oracle, Sybase, & other data sources.

Information Builders (http://www.ibi.com/products/eda/ole_db.html)
supply EDA OLE DB Connector, supporting 35 families of data
sources, including SyBase.

You can find a few more listed (far from an exhaustive list, of
course, but still quite nice) at:
http://ourworld.compuserve.com/homepages/Ken_North/oledbVen.htm


Plus, of course, one thing you can always do with ADO is connect it
to a 'generic OLE DB provider on top of ODBC' which in turn can use
any ODBC data source and present it to you a la OLEdb, and so via
ADO.  This may have some overhead wrt a direct usage of ODBC,
like a direct/native OLEDB provider has some performance advantage
(at least potentially) wrt ODBC, but I don't think that one can measure
it when using a high-level language such as Python (or VB, or ...); if
that level of overhad one way or another was so crucial to you, I think
you'd be programming in C++:-).  Anyway, the existence of the freely
redistributable OLEDB-on-top-of-ODBC ensures that the connectivity
of your ADO-using programs cannot be any smaller than if they used
ODBC directly (and it _can_ be higher -- OLAP, XML, etc, etc).


I _do_ understand the general issue of future-portability-concerns, but
that is why I mentioned the Python Database API -- *that* one lets you
port your programs to other _platforms_, such as Linux rather than NT,
not just to other DBs.  mxODBC can support that, I believe.  And if you
make some effort, you can also use Gadfly (almost-database-API
compliant, I'm told) and see you programs really scream if/when the
database is small enough to fit...!-)

On the other hand, ADO's higher-level view of things (including, but I
don't think this has Sybase support yet, the ADOX extensions for DDL
and security) facilitates porting *between databases* by smoothing
over some of their many niggling differences in terms of SQL dialects
and so on.  So, while currently tying you to Microsoft platforms, it does
make life quite a bit easier in terms of moving between databases,
and its Recordset objects in particular are _very_ easy to use for all
sorts of nice things.  Which is why I think it's worth considering if your
programs are tied to Windows anyway for other reasons...


Alex