On Fri, 20 May 2005 14:34:18 -0500, Anne Toal <[log in to unmask]> wrote:

>On all these lists we can't rely on the members subscribing and unsubscribing themselves. They should be updated based on feeds provided from another computer, such as human resources feeds. Having had no experience doing this, I wanted to check with others who have. Is feeding list membership through a database connection difficult to do? What level of programming skill is needed? What kinds of landmines are waiting for someone attempting this?

Hmmm. To me, the word "feeds" suggests you are updating the LISTSERV list
data on the basis of some data derived from elsewhere.  Essentially this is
synchronization of data between 2 different locations.  The better way, if
you connect LISTSERV to your database, is use the actual data directly from
the database in real-time.  Then you don;t need to 'synchronize' 2 copies in
different formats, you just have 1 copy that server both purposes (mailing
and whatever else HR uses the data for, such as doing payroll, etc.)  The
assumption is that the database is always up-to-date and 100% accurate.

If you connect LISTSERV to a DBMS, then there are basically 2 ways to do it.

One way is you can do mailings via the Site Admin webpage (requires
POSTMASTER= or DIST_ALLOWED_USERS= privileges) using any valid SQL SELECT
statement, which would pull addresses from the database to match whatever
audience you want to receive the message being sent.  LISTSERV does not
provide a means to "store" previously used SELECT statements.  You would
need to do this outside of LISTSERV somehow.  In this method you can have
your data spread across multiple database tables (as good data normalization
practices would suggest you do).  However, since there is no 'list', people
cannot subscribe or unsubscribe.  

The alternative is to configure your database into what appears to LISTSERV
to be a single 'table' (either by means of a "View" feature or re-arranging
your tables, or creating a special table whose values are updated whenever
values in other tables are updated).  Then you have a DBMS-based list, where
the traditional List Header file sits on LISTSERV, but all the subscriber
data resides in this table in the database.  All normal LISTSERV commands
function as usual, (sub/unsub, bounce processing, etc.)  If you are careful
not to conflict with LISTSERV's operations, you can then update the said
table by other processes in the database.

The Developer's guide has a lot more information on this.