Roger, First -- please *always* keep the dbi-users mailing list copied on e-mails. Sending messages just to me won't help others and, in fact, can delay the response you get as others are helpful...
Well, 0.28 is *not* the latest, but that's ActiveState's problem and still not resolved. It's been a LONG time since I released updates to 0.28. See the DBI FAQ at www.xmlproj.com/cgi/fom.cgi for installing "private" updates to the ActiveState binaries. I have a later version of DBI and DBD::ODBC. Also, in my latest development version (not yet released), I have tested some code which may fix your problem, if I read the trace correctly. I'd prefer, though, that you try the latest first and if that doesn't solve it, I'll try the patch. My patch simply sets the column display size to the greater of the column length and the display size. I'm not sure this is a good one overall, but I don't see how it's harmful (yet). Please send me a trace with the new version, just to make sure. Regards, Jeff > -----Original Message----- > From: Roger Magoulas [mailto:roger@;i-loft.com] > Sent: Friday, October 25, 2002 7:10 PM > To: Jeff Urlwin > Subject: Re: Problem Accessing UniVerse data w/ DBI > > > Jeff, > > Since we are running on NT/W2K we are running ActiveState Perl (v. 5.6.1 > build 631). I used the PPM program to load DBI v. 1.201 and DBD::ODBC v. > 0.28. I used PPM to see if there are more recent versions using the search > command and found a newer DBI (v. 1.27) but not a newer DBD::ODBC. I > upgraded to the newer DBI but received the same results. > > Let me know if you need more information. We have been knocking our heads > against the wall trying to figure this one out and appreciate the help. > > Regards, > Roger > > ----- Original Message ----- > From: "Jeff Urlwin" <[EMAIL PROTECTED]> > To: "Roger Magoulas" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, October 25, 2002 3:21 PM > Subject: RE: Problem Accessing UniVerse data w/ DBI > > > > Roger, > > > > Which version of DBD::ODBC are you using? > > > > Regards, > > > > Jeff > > > > > > > We are trying to use Perl/DBI running on W2K to access UniVerse > > > data stored on an AIX machine. We are using the UV ODBC drivers > > > and have created a DSN to access the UniVerse data. We have no > > > problem connecting to the database or running queries via > > > perl/dbi, except that the fetchrow_array() stops when it reaches > > > a row with a column with more than 26 characters. Once we set > > > $dbh->{LongTruncOk} = 1; the fetchrow_array() processes all rows, > > > but all columns are truncated to 26 chars. While we didn't think > > > it relevant (the columns appear as varchar(255), not blobs or > > > text), we set the $dbh->{LongReadLen} = 256 and found no change in > effect. > > > > > > With the dbi trace on we find that once the select is processed > > > there are 2 sets of definition for the columns, the columns are > > > correctly defined as varchars with a length of 254, but they have > > > a second definition with a maxlen = 26 (dbi trace below): > > > > > > dbd_describe sql 31661464: num_fields=3 > > > col 1: VARCHAR len=254 disp= 26, prec=254 scale=0 > > > col 2: VARCHAR len=254 disp= 26, prec=254 scale=0 > > > col 3: VARCHAR len=254 disp= 26, prec=254 scale=0 > > > col 1: 'ADDR1' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=26 > > > col 2: 'MAIL_ADDR1' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=26 > > > col 3: 'MAIL_CSZ' sqltype=VARCHAR, ctype=SQL_C_CHAR, maxlen=26 > > > > > > Using the same ODBC DSN and running queries using the BrioQuery > > > tool, we get no problems. We turned ODBC tracing and found that > > > the connection and the select processing look different in the > > > ODBC logs, via Brio there is no 2nd column definition with the > > > maxlen=26 restriction. > > > > > > We assume Perl/DBI is getting the maxlen from the UniVerse > > > database but don't know how to fix the problem. > > > > > > Thanks in advance for any help. > > > > > > Regards, > > > Roger > > > > > > > > > > > >
