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]>
Tue, 5 Jul 2005 13:29:10 -0400
text/plain (78 lines)
 
Is anyone out there using Oracle DB as Litserv's backend with 14.4?  And if so, have you experienced the following problems?

 

I came in this past weekend to upgrade from 1.8e to 14.4 and discovered that I could no longer subscribe or unsubscribe from any list.  When I attempted to join a list, I received the following DBMS error:

 

>>> 22001/1401: [Microsoft][ODBC driver for Oracle][Oracle]ORA-01401: inserted value too large for column

 

And when I attempted to signoff a list I verified I was subscribe to, I received the following:

 

3 Jul 2005 14:55:49 To   [log in to unmask]: You are not subscribed to the TEST  list under the address your message came (...)

 

The following shows a normal subscribe transaction from the Listserv log prior to the upgrade:

 

3 Jul 2005 02:49:58 From [log in to unmask]: subscribe PRBMDO with topics: text
3 Jul 2005 02:49:58 Connecting to ODBC data source DEFAULT...
3 Jul 2005 02:49:58 Connected to data source SUBS.
SQL> SELECT EMAIL,NAME,PRBMDO FROM LISTSERV WHERE UEMAIL LIKE ? FOR UPDATE OF EMAIL,NAME,PRBMDO,UEMAIL
3 Jul 2005 02:49:59 Connecting to ODBC data source DEFAULT...
3 Jul 2005 02:49:59 Connected to data source SUBS.
SQL> INSERT INTO CHANGELOG (ACTION_DATE,LIST_NAME,OPERATION,PARAM) VALUES({fn NOW()},'PRBMDO','SUBSCRIBE',[log in to unmask] Robert Stamps')
SQL> INSERT INTO CHANGELOG (ACTION_DATE,LIST_NAME,OPERATION,PARAM) VALUES({fn NOW()},'PRBMDO','SET',[log in to unmask] TOPICS: TEXT')
SQL> SELECT EMAIL,NAME,PRBMDO FROM LISTSERV WHERE PRBMDO IS NULL AND UEMAIL = ? FOR UPDATE OF EMAIL,NAME,PRBMDO,UEMAIL
SQL> UPDATE LISTSERV SET EMAIL = ?, NAME = ?, PRBMDO = ?, UEMAIL = ? WHERE UEMAIL = ?
3 Jul 2005 02:49:59 To   [log in to unmask]: You have been added to the APS-PRB-alert list.
3 Jul 2005 02:49:59 To   [log in to unmask]: Your subscription options have been changed to TOPICS: TEXT.
3 Jul 2005 02:49:59 Sent information mail to [log in to unmask]

 

And the following is what was logged after the upgrade (regular subscribe command from an account which already exists in the Listserv table):

 

3 Jul 2005 14:56:39 From [log in to unmask]: subscribe test Claude Etienne
SQL> SELECT EMAIL,NAME,TEST FROM LISTSERV WHERE UEMAIL LIKE ? FOR UPDATE OF EMAIL,NAME,TEST,UEMAIL
3 Jul 2005 14:56:39 Connecting to ODBC data source DEFAULT...
3 Jul 2005 14:56:39 Connected to data source TEAM.
SQL> INSERT INTO CHANGELOG (ACTION_DATE,LIST_NAME,OPERATION,PARAM) VALUES({fn NOW()},'TEST','SUBSCRIBE',[log in to unmask] Claude Etienne')
SQL> SELECT EMAIL,NAME,TEST FROM LISTSERV WHERE TEST IS NULL AND UEMAIL = ? FOR UPDATE OF EMAIL,NAME,TEST,UEMAIL
SQL> INSERT INTO LISTSERV (EMAIL,NAME,TEST,UEMAIL) VALUES(?,?,?,?)
>>> 22001/1401: [Microsoft][ODBC driver for Oracle][Oracle]ORA-01401: inserted value too large for column
>>> 01004/0: [Microsoft][ODBC driver for Oracle]Error in parameter 2: Data truncated
>>> 01004/0: [Microsoft][ODBC driver for Oracle]Error in parameter 3: Data truncated
>>> 01004/0: [Microsoft][ODBC driver for Oracle]Error in parameter 4: Data truncated
>>> 01004/0: [Microsoft][ODBC driver for Oracle]Error in parameter 1: Data truncated
3 Jul 2005 14:56:39 >>> Error X'0100003B' updating DBMS list <<<
3 Jul 2005 14:56:39  -> Severity: Error
3 Jul 2005 14:56:39  -> Facility: DBMS interface
3 Jul 2005 14:56:39  -> Abstract: SQL error
3 Jul 2005 14:56:39 Sent information mail to [log in to unmask]
3 Jul 2005 14:56:39 Sent information mail to [log in to unmask]

 

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.  Being that the EMAIL column is the unique identifier in the Listserv table and each list is represented by a column which is flagged on or off depending on which list a subscriber is subscribed to and the fact that my email ([log in to unmask]) already exists in the table, Listserv should issue an Update and not an Insert???  I also tried subscribing to a list with an account that never existed in the Listserv table and received the same error which kind of goes against my theory about the error being triggered by the integrety constraint on the email column when Listserv tries to do an Insert as oppose to an Update when an account already exists.

 

I verified the structure of both my Listserv table and my Changelog table and nothing changed.  After realizing 14.4 was not working properly, I reverted back to 1.8e and everything worked as it should.

 

Please Help,

Claude.

ATOM RSS1 RSS2