Jeff,
I have installed the versions of the DBI and DBD::ODBC available via the web
site you reference below. Using DBI v. 1.30 and DBD-ODBC v 0.45.18 I
continue the same results, varchar fields are cut-off at 25 characters. What
is different is the trace results no longer show the dbd_describe statements
that included the length and maxlen for the columns included in the select
statment. The trace is set to 9 [DBI->trace(9, 'dbitrace.log');]. The
following is the trace results with the new DBI and DBD::ODBC from the
prepare() to the first row pulled:
-> prepare for DBD::ODBC::db (DBI::db=HASH(0x1d853d0)~0x1d87138 'select
ADDR1, MAIL_ADDR1, MAIL_CSZ
from SG_MEMBER') thr#01ABF3C0
New DBI::st (for DBD::ODBC::st, parent=DBI::db=HASH(0x1d87138), id=)
dbih_setup_handle(DBI::st=HASH(0x1d853e8)=>DBI::st=HASH(0x1e17898),
DBD::ODBC::st, 1d853f4, Null!)
dbih_make_com(DBI::db=HASH(0x1d87138), DBD::ODBC::st, 204) thr#01ABF3C0
dbih_setup_attrib(DBI::st=HASH(0x1e17898), Err, DBI::db=HASH(0x1d87138))
SCALAR(0x1d992c8) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x1e17898), State,
DBI::db=HASH(0x1d87138)) SCALAR(0x1d99310) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x1e17898), Errstr,
DBI::db=HASH(0x1d87138)) SCALAR(0x1d992ec) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x1e17898), Debug,
DBI::db=HASH(0x1d87138)) 0 (already defined)
dbih_setup_attrib(DBI::st=HASH(0x1e17898), FetchHashKeyName,
DBI::db=HASH(0x1d87138)) 'NAME' (already defined)
dbih_setup_attrib(DBI::st=HASH(0x1e17898), HandleError,
DBI::db=HASH(0x1d87138)) undef (not defined)
<- prepare= DBI::st=HASH(0x1d853e8) at D:\bin\calti.pl line 15
>> execute DISPATCH (DBI::st=HASH(0x1d853e8) rc1/1 @1 g0 ima41
pid#2132) at D:\bin\calti.pl line 18
-> execute for DBD::ODBC::st (DBI::st=HASH(0x1d853e8)~0x1e17898)
thr#01ABF3C0
<- execute= -1 at D:\bin\calti.pl line 18
>> fetchrow_array DISPATCH (DBI::st=HASH(0x1d853e8) rc1/1 @1 g1 ima0
pid#2132) at D:\bin\calti.pl line 21
-> fetchrow_array for DBD::ODBC::st (DBI::st=HASH(0x1d853e8)~0x1e17898)
thr#01ABF3C0
dbih_setup_fbav for 3 fields => 0x1ab561c
<- fetchrow_array= ( ' ' ' ' undef ) [3 items] row1 at D:\bin\calti.pl
line 21
>> fetchrow_array DISPATCH (DBI::st=HASH(0x1d853e8) rc1/1 @1 g1 ima0
pid#2132) at D:\bin\calti.pl line 21
-> fetchrow_array for DBD::ODBC::st (DBI::st=HASH(0x1d853e8)~0x1e17898)
thr#01ABF3C0
On this thread Rob Leadbeater suggested changing a parameter on the UniVerse
database and we haven't had an opportunity to try that yet. Let me know if
you need more information or if there is something I need to do get column
information in the trace.
Regards,
Roger
----- Original Message -----
From: "Jeff Urlwin" <[EMAIL PROTECTED]>
To: "Roger Magoulas" <[EMAIL PROTECTED]>; "Jeff Urlwin"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, October 27, 2002 5:58 AM
Subject: RE: Problem Accessing UniVerse data w/ DBI
> 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
