LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Wed, 6 Dec 2006 10:56:02 -0600
text/plain (99 lines)
Liam- Thanks for the followup.

On Dec 4, 2006, at 11:19 AM, Liam Kelly wrote:

>> Thanks Liam, that recompile has gotten me over the hump. Listserv has
>> started up and returns the proper response when I send the 'RELEASE'
>> command.
>
> Good.  I assume you've also made sure that lsv is linked to the  
> unixODBC
> libraries, but lsv_amin is not.

The lsv links to unixODBC have worked although libgcc_s.so still  
seems to be a problem. Exporting via go.user seems to be working as  
mail traffic is being processed as expected.

I am getting connected to my data source just fine but, of course,  
having some new issues that give me some pause. Namely, when a  
command for my list comes into Listserv, I see this on the console:

> 6 Dec 2006 09:58:54 Connecting to UODBC data source CFANS...
> 6 Dec 2006 09:58:54 Connected to data source CFANS.
> 6 Dec 2006 09:58:54 Connecting to UODBC data source CFANS...
> 6 Dec 2006 09:58:54 Connected to data source CFANS.
> >>> S0022/207: [unixODBC][FreeTDS][SQL Server]Invalid column name  
> 'FREETDS_TEST'.
> >>> S0022/207: [unixODBC][FreeTDS][SQL Server]Invalid column name  
> 'FREETDS_TEST'.
> >>> 37000/8180: [unixODBC][FreeTDS][SQL Server]Statement(s) could  
> not be prepared.
> -> Creating FREETDS_TEST column...
> >>> 37000/8180: [unixODBC][FreeTDS][SQL Server]Statement(s) could  
> not be prepared.
> >>> 37000/4909: [unixODBC][FreeTDS][SQL Server]Cannot alter  
> 'VWEMAILTEST' because it is not a table.
> -> Unable to create column!
> >>> S0022/207: [unixODBC][FreeTDS][SQL Server]Invalid column name  
> 'FREETDS_TEST'.
> >>> S0022/207: [unixODBC][FreeTDS][SQL Server]Invalid column name  
> 'FREETDS_TEST'.
> >>> 37000/8180: [unixODBC][FreeTDS][SQL Server]Statement(s) could  
> not be prepared.
> 6 Dec 2006 09:58:54 >>> Error X'0100002B' reading DBMS list <<<
> 6 Dec 2006 09:58:54  -> Severity: Error
> 6 Dec 2006 09:58:54  -> Facility: DBMS interface
> 6 Dec 2006 09:58:54  -> Abstract: No such column

My header file for this list has this DBMS line:
> DBMS= Yes,TABLE(vwEmailTest),Name(Name),EMAIL(email),SERVER(CFANS)

I've verified with isql that:
	select Name,email from vwEmailTest
returns two rows, each containing a fullname and an e-mail address.

My questions:

1. Why is Listserv trying to create columns upon connecting to the  
DSN? Shouldn't it be looking for only the columns I specify in the  
header? I realize I am missing the OPTIONS() pref; does someone have  
an example of this DBMS option/string value?

2. Views don't work? I guess the way I envisioned us implementing the  
DBMS support was this: we provide listserv to our clients, they  
create tables or views on their systems specifically (one per list or  
one table for all lists), they provide us with connection/credential  
information and we configure the DBMS part for them. In production,  
they make changes to the subscription for a given list by changing  
the contents of the table/view. I was thinking of listserv using the  
DBMS sources as read-only as opposed to making changes to the table.

3. I've had problems doing puts with very long DBMS= lines; is there  
a way to specify this one multiple lines and/or is there someway to  
modify LSVROOT/home/listname.list directly (the attempts I've made  
have invalidated that file).

4. Is the recommend method to have one table per DSN with all of the  
information about all of the lists in it? Say a binary value for the  
listname as well as Name and Email for everyone? Has someone got a  
documented example of a working setup (what DBs you're connecting to,  
what the tables look like and how those tables are updated)?

5. If the DBMS support is not going to work in a way that we can use,  
is there a way to dump subscriber lists outside of the listserv  
interfaces (say if we want to query a DB and dump a text file to  
listserv)?

Thanks much!

--
_______________________________________________
Mike Neuharth, BA, LPIC-1
Email/UNIX System Administrator
Internet Services, University of Minnesota
===============================================
"What is important, it seems to me, is not so much to defend a culture
whose existence has never kept a man from going hungry, as to extract,
from what is called culture, ideas whose compelling force is identical
with that of hunger."  -Antonin Artaud

ATOM RSS1 RSS2