> >Three years ago we wrote a program to extract email addresses from a
> >database and load them into a list.  That's not too hard and should
> >also be possible to do with other databases without the DBMS interface.
> >But it does require some programming effort, setting up cron jobs, etc.
> >in each individual case.  So a general interface would be nicer.
>
> The only "general" database interface is ODBC, and even that is only
> general in theory, with a lot of conditional code and hair-pulling.  Other
> than that, every vendor provides an API and you have the usual trade-off
> between development/testing time and market share. The code must be
> compiled (and the API/client licensed) separately for each operating system
> you want to support, and the API can even change radically from one
> version to another. For instance, version 8 of OCI is a major rewrite of
> version 7 with most of the functions and constants renamed.
>
> Anyway, the native API for SQL Server is ODBC, so if you want to
> interface to SQL Server the simplest solution is by far a LISTSERV
> server on a system with ODBC (ie NT). The alternatives are much
> more complex and generally very expensive, although you may already
> own the necessary licenses for unrelated reasons.
>
>   Eric

I understand what you are saying about cost-benefit.

Right now I'm just trying to figure out what the possible applications
might be.  I think we have some sort of ODBC interface to DB2, but I have
no idea where it comes from.  But as you say, we'd need NT LISTSERV to
use it.  We'd have to think carefully about whether the additional
overhead of another LISTSERV system would be justified.