Skip Menu |

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 78186
Status: resolved
Priority: 0/
Queue: DBD-ODBC
People
Owner: Nobody in particular
Requestors: gregory.ionis [...] baml.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)
Attachments
odbc.log
odbc.txt

History Show all quoted text
  Tue Jul 03 18:22:04 2012 gregory.ionis [...] baml.com - Ticket created
Subject: Issue when DBD::ODBC upgraded from 1.24 to 1.37
Date: Tue, 03 Jul 2012 18:21:50 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
I have upgraded my DBD::ODBC from version 1.24 to version 1.37 and I observed two problems: 1)Previously I could connect with the following DSN: dbi:ODBC:Driver=libdbodbc11.so;ServerName=server;links=tcpip{host=host;p ort=port} Now it fails to connect with error [unixODBC][Driver Manager]Data source name not found, and no default driver specified (SQL-IM002)' (err#0) Using a predefined DSN (same as before) it connects without a problem. 2)I am using the FreeTDS driver, which does not return column types, so DBD::ODBC automaticall;y converts data to varchar. However, this convertion changed. Specifically, I have a FLOAT value. In the old version it is returned as .002983792917, and in the new version as .00298. I have looked through the release notes for DBD::ODBC, but have not found anything relevant. Please let me know if you need any additional details. Thank you for your help, Gregory Ionis ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
  Wed Jul 04 04:19:55 2012 bohica [...] ntlworld.com - Correspondence added
On Tue Jul 03 18:22:04 2012, gregory.ionis@baml.com wrote: Thanks for your report. Show quoted text
> I have upgraded my DBD::ODBC from version 1.24 to version 1.37 and I > observed two problems:
I hate to think how much has changed since then. What platform are you running on and how was DBD::ODBC built? If didn't build it yourself can you get a connection up in Perl and print odbc_has_unicode read-only attribute out. What driver manager and version of it are you using? If it is unixODBC can you run odbcinst -j. Show quoted text
> 1)Previously I could connect with the following DSN: > > dbi:ODBC:Driver=libdbodbc11.so;ServerName=server;links=tcpip{host=host;p > ort=port}
Show quoted text
> Now it fails to connect with error > > [unixODBC][Driver Manager]Data source name not found, and no default > driver specified (SQL-IM002)' (err#0) > > Using a predefined DSN (same as before) it connects without a problem.
Below you say you are using freeTDS and that does not look like a freeTDS driver shared object - can you explain. IF you've got a recent version of DBI (1.617 or above) could you repeat the above code but set and export DBI_TRACE=DBD=x.log and attach a log file. If you have not got a recent DBI could you add the following to your Perl code at the start, set and export DBI_TRACE=15=x.log and rerun it then send me the log: use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode')); Lastly, try changing Driver= to DRIVER= but if this works I'd still like to see the log files please. Show quoted text
> 2)I am using the FreeTDS driver, which does not return column types,
Really. You mean SQLDescribeCol on a result-set cannot tell you what the column is? In other words after issuing a select, the TYPE attribute does not return column types. Show quoted text
> so > DBD::ODBC automaticall;y converts data to varchar. However, this > convertion changed. Specifically, I have a FLOAT value. In the old > version it is returned as .002983792917, and in the new version as > .00298.
Could you reduce your code to a very small example (preferably one which creates the schema too and populates some date) and send me it? Show quoted text
> I have looked through the release notes for DBD::ODBC, but have not > found anything relevant.
Show quoted text
> Please let me know if you need any additional details. > > Thank you for your help, > Gregory Ionis
BTW, if you don't want to attach log files to the RT you can send them to my CPAN address mjevans@cpan.org. Martin -- Martin J. Evans Wetherby, UK
  Wed Jul 04 04:19:56 2012 The RT System itself - Status changed from 'new' to 'open'
  Tue Aug 07 12:11:57 2012 gregory.ionis [...] baml.com - Correspondence added
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
Date: Tue, 07 Aug 2012 12:11:35 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
Martin, I think I got some progress. I have 64-bit unixODBC and DBD::ODBC now. Running the same sample again, I observe the following (please let me know if I am wrong): 1)For the FLOAT result driver reports type REAL with 13 character-long display. 2)DBD::ODBC regards it as SQL_LONGVARBINARY (not sure if this is as it should be). 3)If I do not set LongTruncOk=1, it will fail with the same error. 4)However, if I do set LongTruncOk=1, looking at the result in the debugger, I see "123.456001281\c@", which is 14 characters long, with the last character being NUL (0x0). Now in the guessing territory: the driver says 13-character string, but returns a 13-character NUL-terminated C string, thus causing "too much data" condition. I am not sure whose fault this is -- the Sybase driver, or DBD::ODBC (either there should be no NUL character in BINARY type, or it should classify it as a TEXT type of some kind to get the string representation correctly). Am I making any sense? Note that it is not every FLOAT value that causes this (extra NUL) situation. I initially thought that only small values cause this, but this is clearly not the case, and I do not see any pattern. Attached are the Perl source and the log. Thank you for your help, Gregory Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Wednesday, July 04, 2012 4:20 AM To: Ionis, Gregory - RSCH AMRS Subject: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37 <URL: https://rt.cpan.org/Ticket/Display.html?id=78186 > On Tue Jul 03 18:22:04 2012, gregory.ionis@baml.com wrote: Thanks for your report.
> I have upgraded my DBD::ODBC from version 1.24 to version 1.37 and I > observed two problems:
I hate to think how much has changed since then. What platform are you running on and how was DBD::ODBC built? If didn't build it yourself can you get a connection up in Perl and print odbc_has_unicode read-only attribute out. What driver manager and version of it are you using? If it is unixODBC can you run odbcinst -j.
> 1)Previously I could connect with the following DSN: > > dbi:ODBC:Driver=libdbodbc11.so;ServerName=server;links=tcpip{host=host > ;p > ort=port}
> Now it fails to connect with error > > [unixODBC][Driver Manager]Data source name not found, and no default > driver specified (SQL-IM002)' (err#0) > > Using a predefined DSN (same as before) it connects without a problem.
Below you say you are using freeTDS and that does not look like a freeTDS driver shared object - can you explain. IF you've got a recent version of DBI (1.617 or above) could you repeat the above code but set and export DBI_TRACE=DBD=x.log and attach a log file. If you have not got a recent DBI could you add the following to your Perl code at the start, set and export DBI_TRACE=15=x.log and rerun it then send me the log: use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode')); Lastly, try changing Driver= to DRIVER= but if this works I'd still like to see the log files please.
> 2)I am using the FreeTDS driver, which does not return column types,
Really. You mean SQLDescribeCol on a result-set cannot tell you what the column is? In other words after issuing a select, the TYPE attribute does not return column types.
> so > DBD::ODBC automaticall;y converts data to varchar. However, this > convertion changed. Specifically, I have a FLOAT value. In the old > version it is returned as .002983792917, and in the new version as > .00298.
Could you reduce your code to a very small example (preferably one which creates the schema too and populates some date) and send me it?
> I have looked through the release notes for DBD::ODBC, but have not > found anything relevant.
> Please let me know if you need any additional details. > > Thank you for your help, > Gregory Ionis
BTW, if you don't want to attach log files to the RT you can send them to my CPAN address mjevans@cpan.org. Martin -- Martin J. Evans Wetherby, UK ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Message body is not shown because sender requested not to inline it.

Download odbc.log
application/octet-stream 15.3k

Message body not shown because it is not plain text.

  Tue Aug 07 12:14:09 2012 gregory.ionis [...] baml.com - Correspondence added
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
Date: Tue, 07 Aug 2012 12:13:49 -0400
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
Sorry, forgot to mention that the explicit DSN (same as I was using before) is working now. Thank you, Gregory Show quoted text
-----Original Message----- From: Ionis, Gregory - RSCH AMRS Sent: Tuesday, August 07, 2012 12:12 PM To: 'bug-DBD-ODBC@rt.cpan.org' Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37 Martin, I think I got some progress. I have 64-bit unixODBC and DBD::ODBC now. Running the same sample again, I observe the following (please let me know if I am wrong): 1)For the FLOAT result driver reports type REAL with 13 character-long display. 2)DBD::ODBC regards it as SQL_LONGVARBINARY (not sure if this is as it should be). 3)If I do not set LongTruncOk=1, it will fail with the same error. 4)However, if I do set LongTruncOk=1, looking at the result in the debugger, I see "123.456001281\c@", which is 14 characters long, with the last character being NUL (0x0). Now in the guessing territory: the driver says 13-character string, but returns a 13-character NUL-terminated C string, thus causing "too much data" condition. I am not sure whose fault this is -- the Sybase driver, or DBD::ODBC (either there should be no NUL character in BINARY type, or it should classify it as a TEXT type of some kind to get the string representation correctly). Am I making any sense? Note that it is not every FLOAT value that causes this (extra NUL) situation. I initially thought that only small values cause this, but this is clearly not the case, and I do not see any pattern. Attached are the Perl source and the log. Thank you for your help, Gregory
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Wednesday, July 04, 2012 4:20 AM To: Ionis, Gregory - RSCH AMRS Subject: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37 <URL: https://rt.cpan.org/Ticket/Display.html?id=78186 > On Tue Jul 03 18:22:04 2012, gregory.ionis@baml.com wrote: Thanks for your report.
> I have upgraded my DBD::ODBC from version 1.24 to version 1.37 and I > observed two problems:
I hate to think how much has changed since then. What platform are you running on and how was DBD::ODBC built? If didn't build it yourself can you get a connection up in Perl and print odbc_has_unicode read-only attribute out. What driver manager and version of it are you using? If it is unixODBC can you run odbcinst -j.
> 1)Previously I could connect with the following DSN: > > dbi:ODBC:Driver=libdbodbc11.so;ServerName=server;links=tcpip{host=host > ;p > ort=port}
> Now it fails to connect with error > > [unixODBC][Driver Manager]Data source name not found, and no default > driver specified (SQL-IM002)' (err#0) > > Using a predefined DSN (same as before) it connects without a problem.
Below you say you are using freeTDS and that does not look like a freeTDS driver shared object - can you explain. IF you've got a recent version of DBI (1.617 or above) could you repeat the above code but set and export DBI_TRACE=DBD=x.log and attach a log file. If you have not got a recent DBI could you add the following to your Perl code at the start, set and export DBI_TRACE=15=x.log and rerun it then send me the log: use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode')); Lastly, try changing Driver= to DRIVER= but if this works I'd still like to see the log files please.
> 2)I am using the FreeTDS driver, which does not return column types,
Really. You mean SQLDescribeCol on a result-set cannot tell you what the column is? In other words after issuing a select, the TYPE attribute does not return column types.
> so > DBD::ODBC automaticall;y converts data to varchar. However, this > convertion changed. Specifically, I have a FLOAT value. In the old > version it is returned as .002983792917, and in the new version as > .00298.
Could you reduce your code to a very small example (preferably one which creates the schema too and populates some date) and send me it?
> I have looked through the release notes for DBD::ODBC, but have not > found anything relevant.
> Please let me know if you need any additional details. > > Thank you for your help, > Gregory Ionis
BTW, if you don't want to attach log files to the RT you can send them to my CPAN address mjevans@cpan.org. Martin -- Martin J. Evans Wetherby, UK ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
  Thu Aug 09 05:27:41 2012 bohica [...] ntlworld.com - Correspondence added
On Tue Aug 07 12:11:57 2012, gregory.ionis@baml.com wrote: Show quoted text
> Martin, > > I think I got some progress. I have 64-bit unixODBC and DBD::ODBC now. > Running the same sample again, I observe the following (please let me > know if I am wrong): > > 1)For the FLOAT result driver reports type REAL with 13 character-long > display.
From the log file the driver reports: DescribeCol column = 1, name = flt, namelen = 3, type = REAL(7), precision/column size = 7, scale = 0, nullable = 0 SQL_COLUMN_DISPLAY_SIZE = 13 <---- NOTE THIS IS WHAT THE DRIVER SAID SQL_COLUMN_LENGTH = 7 now using col 1: type = REAL (7), len = 7, display size = 14, prec = 7, scale = 0 NOTE: we are using a display size of 14 (1 more than the 13 reported) DescribeCol column = 2, name = dbl, namelen = 3, type = DOUBLE(8), precision/column size = 15, scale = 0, nullable = 0 SQL_COLUMN_DISPLAY_SIZE = 22 SQL_COLUMN_LENGTH = 15 now using col 2: type = DOUBLE (8), len = 15, display size = 23, prec = 15, scale = 0 as above DescribeCol column = 3, name = num, namelen = 3, type = NUMERIC(2), precision/column size = 36, scale = 30, nullable = 0 SQL_COLUMN_DISPLAY_SIZE = 38 SQL_COLUMN_LENGTH = 38 now using col 3: type = NUMERIC (2), len = 38, display size = 39, prec = 36, scale = 30 then it bound them all as chars as got a data truncation which should not happen as all buffers passed were 1 bigger than the driver reported: Bind 1: type = CHAR(1), buf=14adfc60, buflen=14 Bind 2: type = CHAR(1), buf=14adfc70, buflen=23 Bind 3: type = CHAR(1), buf=14adfc88, buflen=39 Show quoted text
> 2)DBD::ODBC regards it as SQL_LONGVARBINARY (not sure if this is as it > should be).
What makes you think that? You did not provide the output from the script you attached. Show quoted text
> 3)If I do not set LongTruncOk=1, it will fail with the same error.
because that is what LongTruncOk does. Show quoted text
> 4)However, if I do set LongTruncOk=1, looking at the result in the > debugger, I see "123.456001281\c@", which is 14 characters long, with > the last character being NUL (0x0).
All strings are nul terminated. DBD::ODBC provided a buffer of 14 bytes, the driver had no choice but to write up to 13 bytes + a Nul or it would have gone off the end of the buffer. The driver reported data truncation so that suggests the driver thinks it can write more than 13 chrs for the the real BUT it told us the display size was 13 so it lied. Show quoted text
> Now in the guessing territory: the driver says 13-character string, > but > returns a 13-character NUL-terminated C string, thus causing "too much > data" condition. I am not sure whose fault this is -- the Sybase > driver, > or DBD::ODBC (either there should be no NUL character in BINARY type, > or > it should classify it as a TEXT type of some kind to get the string > representation correctly). Am I making any sense?
yes, a reasonable guess but see my last comment above. Show quoted text
> Note that it is not every FLOAT value that causes this (extra NUL) > situation. I initially thought that only small values cause this, but > this is clearly not the case, and I do not see any pattern.
The NUL is not the issue, I believe the driver is lying. Show quoted text
> Attached are the Perl source and the log. > > Thank you for your help, > Gregory
There is no easy way to prove the problem unless you are able to edit DBD::ODBC and rebuild it. If you are then you could artificially increment the value returned for SQL_COLUMN_DISPLAY_SIZE and prove the driver wants to write more in the buffer than it told us it could. If you can do that let me know and I'll tell you which line to change. It may be useful if I knew some of the details about unixODBC I asked you in the first email e.g., odbcinst -j and whether odbc_has_unicode is enabled? Martin -- Martin J. Evans Wetherby, UK
  Fri Sep 07 05:00:56 2012 bohica [...] ntlworld.com - Status changed from 'open' to 'stalled'
  Thu Nov 29 04:59:13 2012 bohica [...] ntlworld.com - Correspondence added
On Thu Aug 09 05:27:41 2012, MJEVANS wrote: Show quoted text
> On Tue Aug 07 12:11:57 2012, gregory.ionis@baml.com wrote:
> > Martin, > > > > I think I got some progress. I have 64-bit unixODBC and DBD::ODBC
now. Show quoted text
> > Running the same sample again, I observe the following (please let
me Show quoted text
> > know if I am wrong): > > > > 1)For the FLOAT result driver reports type REAL with 13 character-
long Show quoted text
> > display.
> > From the log file the driver reports: > > DescribeCol column = 1, name = flt, namelen = 3, type = REAL(7), > precision/column size = 7, scale = 0, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 13 <---- NOTE THIS IS WHAT THE DRIVER
SAID Show quoted text
> SQL_COLUMN_LENGTH = 7 > now using col 1: type = REAL (7), len = 7, display size = 14,
prec Show quoted text
> = 7, scale = 0 > > NOTE: we are using a display size of 14 (1 more than the 13 reported) > > DescribeCol column = 2, name = dbl, namelen = 3, type = DOUBLE(8), > precision/column size = 15, scale = 0, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 22 > SQL_COLUMN_LENGTH = 15 > now using col 2: type = DOUBLE (8), len = 15, display size = 23, > prec = 15, scale = 0 > > as above > > DescribeCol column = 3, name = num, namelen = 3, type =
NUMERIC(2), Show quoted text
> precision/column size = 36, scale = 30, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 38 > SQL_COLUMN_LENGTH = 38 > now using col 3: type = NUMERIC (2), len = 38, display size = 39, > prec = 36, scale = 30 > > then it bound them all as chars as got a data truncation which should > not happen as all buffers passed were 1 bigger than the driver
reported: Show quoted text
> > Bind 1: type = CHAR(1), buf=14adfc60, buflen=14 > Bind 2: type = CHAR(1), buf=14adfc70, buflen=23 > Bind 3: type = CHAR(1), buf=14adfc88, buflen=39 >
> > 2)DBD::ODBC regards it as SQL_LONGVARBINARY (not sure if this is as
it Show quoted text
> > should be).
> > What makes you think that? You did not provide the output from the > script you attached. >
> > 3)If I do not set LongTruncOk=1, it will fail with the same error.
> > because that is what LongTruncOk does. >
> > 4)However, if I do set LongTruncOk=1, looking at the result in the > > debugger, I see "123.456001281\c@", which is 14 characters long,
with Show quoted text
> > the last character being NUL (0x0).
> > All strings are nul terminated. DBD::ODBC provided a buffer of 14
bytes, Show quoted text
> the driver had no choice but to write up to 13 bytes + a Nul or it
would Show quoted text
> have gone off the end of the buffer. The driver reported data
truncation Show quoted text
> so that suggests the driver thinks it can write more than 13 chrs for > the the real BUT it told us the display size was 13 so it lied. >
> > Now in the guessing territory: the driver says 13-character string, > > but > > returns a 13-character NUL-terminated C string, thus causing "too
much Show quoted text
> > data" condition. I am not sure whose fault this is -- the Sybase > > driver, > > or DBD::ODBC (either there should be no NUL character in BINARY
type, Show quoted text
> > or > > it should classify it as a TEXT type of some kind to get the string > > representation correctly). Am I making any sense?
> > yes, a reasonable guess but see my last comment above. >
> > Note that it is not every FLOAT value that causes this (extra NUL) > > situation. I initially thought that only small values cause this,
but Show quoted text
> > this is clearly not the case, and I do not see any pattern.
> > The NUL is not the issue, I believe the driver is lying. >
> > Attached are the Perl source and the log. > > > > Thank you for your help, > > Gregory
> > There is no easy way to prove the problem unless you are able to edit > DBD::ODBC and rebuild it. If you are then you could artificially > increment the value returned for SQL_COLUMN_DISPLAY_SIZE and prove the > driver wants to write more in the buffer than it told us it could. If > you can do that let me know and I'll tell you which line to change. > > It may be useful if I knew some of the details about unixODBC I asked > you in the first email e.g., odbcinst -j and whether odbc_has_unicode
is Show quoted text
> enabled? > > Martin
This issue has not had any comments in a long time. My analysis is that your ODBC driver is broken and it is not an issue with DBD::ODBC. Do you have any issue with me closing this rt now? Martin -- Martin J. Evans Wetherby, UK
  Thu Nov 29 04:59:14 2012 The RT System itself - Status changed from 'stalled' to 'open'
  Thu Nov 29 08:46:07 2012 gregory.ionis [...] baml.com - Correspondence added
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
Date: Thu, 29 Nov 2012 08:45:51 -0500
To: "'bug-DBD-ODBC [...] rt.cpan.org'" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
Please close it. I am using a work-around for now, and have not had the time to dig deeper into the ODBC driver. Thank you for your help, Gregory Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Thursday, November 29, 2012 4:59 AM To: Ionis, Gregory - RSCH AMRS Subject: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37 <URL: https://rt.cpan.org/Ticket/Display.html?id=78186 > On Thu Aug 09 05:27:41 2012, MJEVANS wrote:
> On Tue Aug 07 12:11:57 2012, gregory.ionis@baml.com wrote:
> > Martin, > > > > I think I got some progress. I have 64-bit unixODBC and DBD::ODBC
now.
> > Running the same sample again, I observe the following (please let
me
> > know if I am wrong): > > > > 1)For the FLOAT result driver reports type REAL with 13 character-
long
> > display.
> > From the log file the driver reports: > > DescribeCol column = 1, name = flt, namelen = 3, type = REAL(7), > precision/column size = 7, scale = 0, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 13 <---- NOTE THIS IS WHAT THE DRIVER
SAID
> SQL_COLUMN_LENGTH = 7 > now using col 1: type = REAL (7), len = 7, display size = 14,
prec
> = 7, scale = 0 > > NOTE: we are using a display size of 14 (1 more than the 13 reported) > > DescribeCol column = 2, name = dbl, namelen = 3, type = DOUBLE(8), > precision/column size = 15, scale = 0, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 22 > SQL_COLUMN_LENGTH = 15 > now using col 2: type = DOUBLE (8), len = 15, display size = 23, > prec = 15, scale = 0 > > as above > > DescribeCol column = 3, name = num, namelen = 3, type =
NUMERIC(2),
> precision/column size = 36, scale = 30, nullable = 0 > SQL_COLUMN_DISPLAY_SIZE = 38 > SQL_COLUMN_LENGTH = 38 > now using col 3: type = NUMERIC (2), len = 38, display size = 39, > prec = 36, scale = 30 > > then it bound them all as chars as got a data truncation which should > not happen as all buffers passed were 1 bigger than the driver
reported:
> > Bind 1: type = CHAR(1), buf=14adfc60, buflen=14 > Bind 2: type = CHAR(1), buf=14adfc70, buflen=23 > Bind 3: type = CHAR(1), buf=14adfc88, buflen=39 >
> > 2)DBD::ODBC regards it as SQL_LONGVARBINARY (not sure if this is as
it
> > should be).
> > What makes you think that? You did not provide the output from the > script you attached. >
> > 3)If I do not set LongTruncOk=1, it will fail with the same error.
> > because that is what LongTruncOk does. >
> > 4)However, if I do set LongTruncOk=1, looking at the result in the > > debugger, I see "123.456001281\c@", which is 14 characters long,
with
> > the last character being NUL (0x0).
> > All strings are nul terminated. DBD::ODBC provided a buffer of 14
bytes,
> the driver had no choice but to write up to 13 bytes + a Nul or it
would
> have gone off the end of the buffer. The driver reported data
truncation
> so that suggests the driver thinks it can write more than 13 chrs for > the the real BUT it told us the display size was 13 so it lied. >
> > Now in the guessing territory: the driver says 13-character string, > > but > > returns a 13-character NUL-terminated C string, thus causing "too
much
> > data" condition. I am not sure whose fault this is -- the Sybase > > driver, > > or DBD::ODBC (either there should be no NUL character in BINARY
type,
> > or > > it should classify it as a TEXT type of some kind to get the string > > representation correctly). Am I making any sense?
> > yes, a reasonable guess but see my last comment above. >
> > Note that it is not every FLOAT value that causes this (extra NUL) > > situation. I initially thought that only small values cause this,
but
> > this is clearly not the case, and I do not see any pattern.
> > The NUL is not the issue, I believe the driver is lying. >
> > Attached are the Perl source and the log. > > > > Thank you for your help, > > Gregory
> > There is no easy way to prove the problem unless you are able to edit > DBD::ODBC and rebuild it. If you are then you could artificially > increment the value returned for SQL_COLUMN_DISPLAY_SIZE and prove the > driver wants to write more in the buffer than it told us it could. If > you can do that let me know and I'll tell you which line to change. > > It may be useful if I knew some of the details about unixODBC I asked > you in the first email e.g., odbcinst -j and whether odbc_has_unicode
is
> enabled? > > Martin
This issue has not had any comments in a long time. My analysis is that your ODBC driver is broken and it is not an issue with DBD::ODBC. Do you have any issue with me closing this rt now? Martin -- Martin J. Evans Wetherby, UK ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
  Thu Nov 29 08:57:37 2012 bohica [...] ntlworld.com - Correspondence added
Closing after correspondence with OP "Please close it. I am using a work-around for now, and have not had the time to dig deeper into the ODBC driver." Martin -- Martin J. Evans Wetherby, UK
  Thu Nov 29 08:57:37 2012 bohica [...] ntlworld.com - Status changed from 'open' to 'resolved'