I was using freetds-0.61.2 I have brought my checked out copy of freetds up to head and have built it just now with iodbc and unixodbc enabled. As ever, it is difficult for me to get my head around all the configuration stuff ... I would love to be able to give DBD::ODBC a DBI_DSN which is just a list of name value pairs (the right name/value pairs of course!) to enable me to run the test suite against a M$ SQL 2000 server.
pjjH -----Original Message----- From: Jeff Urlwin [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2003 1:52 PM To: Harrington, Paul Cc: [EMAIL PROTECTED] Subject: RE: Problem with DBD::ODBC misinterpreting CHAR columns as VARCHAR so the DBI ChopBlanks attribute 'not working' Well, that's some good news. Are you using a specific version of FreeTDS or accessing the CVS repository directly? Jeff > -----Original Message----- > From: Harrington, Paul [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 1:37 PM > To: Jeff Urlwin > Cc: [EMAIL PROTECTED] > Subject: RE: Problem with DBD::ODBC misinterpreting CHAR > columns as VARCHAR so the DBI ChopBlanks attribute 'not working' > > > right, but DBD::Sybase over FreeTDS doesn't have placeholders > yet which is why we commissioned Micheal to write > DBD::FreeTDS but the ct-lib support in FreeTDS does not > include placeholders which is why I wanted to try DBD::ODBC > ... with the exception of the 'char columns appearing as > varchars', DBD::ODBC with iODBC/FreeTDS is working quite nicely. > > pjjH > > -----Original Message----- > From: Jeff Urlwin [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2003 12:51 PM > To: Harrington, Paul > Cc: [EMAIL PROTECTED] > Subject: RE: Problem with DBD::ODBC misinterpreting CHAR > columns as VARCHAR so the DBI ChopBlanks attribute 'not working' > > > > 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 > > > > > > > > > > > > > > > > > > > >
