If you are using Class::DBI, I don't know. I would suspect, though, that FreeTDS would work better with DBD::Sybase, since DBD::Sybase operates at the lower level. With DBD::ODBC, you are requiring an extra level (their ODBC driver) to work in addition to the basic protocols.
Regards, Jeff > -----Original Message----- > From: Harrington, Paul [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 12:24 PM > To: Jeff Urlwin > Cc: Harrington, Paul > Subject: RE: Problem with DBD::ODBC misinterpreting CHAR > columns as VARCHAR so the DBI ChopBlanks attribute 'not working' > > > Hi Jeff, > where would I put that in? I am using Class::DBI and am > insulated from a lot of the details. I enclose a message I > just sent to Michael Peppler (who we have contracted to do > some work on DBD::FreeTDS) with some extracts of runs > comparing DBD::Sybase and DBD::ODBC with DBI_TRACE set to 9. > > pjjH > > -----Original Message----- > From: Jeff Urlwin [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2003 2:14 PM > To: Harrington, Paul; [EMAIL PROTECTED] > Subject: RE: Problem with DBD::ODBC misinterpreting CHAR > columns as VARCHAR so the DBI ChopBlanks attribute 'not working' > > > > > > > Hi, > > appended is a message I sent to the FreeTDS list earlier on > > today. I am having problems with trailing blanks in CHAR > > fields despite the DBI ChopBlanks attribute being set. I had > > thought that the type information returned to DBD::ODBC was > > incorrect because of some FreeTDS problem. However, since > > then I used the isql program and the 'help' command. The > > column type is correctly reported as being of type CHAR(30) > > > > any idea why the CHAR(30) should be reported as being a VARCHAR(30)? > > any low-level workarounds for ChopBlanks? I don't want to > > have fixup all of the data at the application level. > > That's probably coming from the driver, which is in FreeTDS. > You can force it using bind_param to SQL_CHAR type and that > should help. > > Jeff > > > > > > thanks in advance, > > > > pjjH > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Harrington, Paul > > Sent: Monday, October 13, 2003 1:30 PM > > To: FreeTDS Development Group > > Subject: [freetds] Weird problem with CHAR columns being > > reported as VARCHARcolumns with FreeTDS 0.61.2,DBD::ODBC and > > unixODBC and iODBC talking to SQL Server 2000,perl 5.8.1 on Solaris > > > > > > Hi, > > I thought that I was having problems with the ChopBlanks > > attribute being honored in DBD::ODBC as any of my tests with > > CHAR columns were failing because of trailing spaces. > > However, on checking into it a bit closer, it seems that the > > columns in the result set are being described as varchar > > rather than char. The retrieved values do not contain > > trailing spaces when I access the database with DBD::Sybase > > built over the same revision of FreeTDS (but -- of course -- > > going over ct-lib). > > > > any ideas as to why unixODBC and iODBC seem to be > > interpreting the column as a varchar rather than a char? > > > > pjjH > > > > [details] > > > > The condition (line 2226 of dbdimp.c in DBD-ODBC-1.06) is: > > if (ChopBlanks && fbh->ColSqlType == SQL_CHAR && > > fbh->datalen > 0) { > > > > > > on checking the DBI trace with freetds, I see: > > > > colname 14 = nodmst_name, len = 11 (194) > > col 14: VARCHAR len= 30 disp= 31, prec= 30 scale=0 > > > > > > > > This is the (section of the) output I get from sp_help for > the table. > > > > nodmst_name > > > > > > > > > > > > > > char > > > > > > > > > > > > > > no 30 > > yes no > > > > yes > > SQL_Latin1_General_CP1_CI_AS > > > > > > > > > > > > > > _______________________________________________ > > FreeTDS mailing list > > [EMAIL PROTECTED] > > http://lists.ibiblio.org/mailman/listinfo/free> tds > > > > > > > > > > >
