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
Claude Etienne <[log in to unmask]>
Wed, 6 Jul 2005 12:08:55 -0400
text/plain (52 lines)
Hi Eric,

All columns in my Listserv table are defined as varchar2(128).

I'll enable tracing on the driver and try the installation again maybe this
coming weekend to see what I can learn from it.  But I am curious to know
how many people on this list use a DBMS (specifically Oracle 8i) for their
lists?  I don't think many do.  If it works for someone else and not for me,
then maybe I can try something on my end like changing the driver I use for
the DSN.  What is weird to me is that it's able to insert values in my
changelog table, which uses the same DSN, fine.  The web interface was able
to show me who is on any list but would not let me add or delete via the web
or email.  The web interface queries the table fine so it maybe something
specific with using a SELECT FOR UPDATE statement...just not sure.


Thanks,
Claude.
----- Original Message -----
From: "Eric Thomas" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, July 06, 2005 11:15 AM
Subject: Re: LISTSERV DBMS ISSUE


> >It looks like Listserv is issuing an INSERT statement as oppose to an
> >UPDATE statement which could possible mean that the SELECT FOR UPDATE
> >statement prior to the INSERT (or the SELECT FOR UPDATE statement that
> >verifies whether or not an email is already subscribed to a list) returns
> >an empty recordset.
>
> I agree that this seems to be the case. I suggest enabling tracing in the
> ODBC driver to see what is happening. It is difficult to say more without
> this information. As you can see from the logs, the sequence of SQL
> statements is the same, except for the final one. That is, LISTSERV does
> look for an existing record before deciding to use INSERT rather than
> UPDATE. Presumably, there is a problem with this SELECT. I also wonder how
> the columns referred in the SELECT are defined (type, length, etc).
>
> There have not been any changes at all in the high-level DBMS code in
14.4,
> but there were quite a few such changes in 14.3. So I suspect you would
have
> the same results with 14.3 if you tried it. Conversely, a site that does
not
> experience this problem with 14.3 is unlikely to get in trouble by
> installing 14.4. I cannot promise anything since low-level database
drivers
> may have changed, but in principle there is no DBMS change in 14.4.
>
>   Eric

ATOM RSS1 RSS2