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)



From gregory.ionis [...] baml.com Tue Jul 3 18: 22:03 2012
X-Originalarrivaltime: 03 Jul 2012 22:21:51.0848 (UTC) FILETIME=[3ECA8E80:01CD596A]
MIME-Version: 1.0
X-Spam-Status: No, score=-1.238 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, HDRS_LCASE=3.891, MANY_HDRS_LCASE=1.106, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=no
Content-Class: urn:content-classes:message
X-Spam-Flag: NO
content-type: text/plain; charset="utf-8"
Message-ID: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-MS-Tnef-Correlator:
X-Spam-Score: -1.238
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 6ED0A240372 for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 3 Jul 2012 18:22:03 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhvDJ6pxQK4Z for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 3 Jul 2012 18:22:01 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 3537C2403DA for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 3 Jul 2012 18:22:00 -0400 (EDT)
Received: (qmail 27573 invoked by uid 103); 3 Jul 2012 22:22:00 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 3 Jul 2012 22:22:00 -0000
Received: from txmx08.bankofamerica.com (HELO txdmzmailmx08.bankofamerica.com) (171.161.160.26) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Tue, 03 Jul 2012 15:21:57 -0700
Received: from txdmzmailmx07.bankofamerica.com ([171.180.168.234]) by txdmzmailmx08.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q63MLro1009437 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 3 Jul 2012 22:21:53 GMT
Received: from memtx2mta03.bankofamerica.com (memtx2mta03.bankofamerica.com [171.186.232.156]) by txdmzmailmx07.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q63MLodF016272 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 3 Jul 2012 22:21:53 GMT
Delivered-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
Subject: Issue when DBD::ODBC upgraded from 1.24 to 1.37
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-07-03_09:2012-07-03,2012-07-03,1970-01-01 signatures=0
Return-Path: <gregory.ionis [...] baml.com>
Thread-Index: Ac1Zaj5kd2OaoFuWQoaXuTdgQqc6Iw==
X-RT-Mail-Extension: dbd-odbc
X-Original-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
X-Spam-Check-BY: 16.mx.develooper.com
Date: Tue, 03 Jul 2012 18:21:50 -0400
X-Spam-Level:
X-MS-Has-Attach:
Thread-Topic: Issue when DBD::ODBC upgraded from 1.24 to 1.37
X-Mimeole: Produced By Microsoft Exchange V6.5
To: bug-DBD-ODBC [...] rt.cpan.org
Content-Transfer-Encoding: 7BIT
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
X-RT-Original-Encoding: US-ASCII
Content-Length: 2806
Download (untitled) / with headers
text/plain 2.7k
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.
MIME-Version: 1.0
In-Reply-To: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-21177-1341389995-1419.78186-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 2458
Download (untitled) / with headers
text/plain 2.4k
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
From gregory.ionis [...] baml.com Tue Aug 7 12: 11:56 2012
X-Originalarrivaltime: 07 Aug 2012 16:11:35.0927 (UTC) FILETIME=[51874870:01CD74B7]
MIME-Version: 1.0
X-Spam-Status: No, score=-3.737 tagged_above=-99.9 required=10 tests=[AWL=2.498, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
In-Reply-To: <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org>
Content-Class: urn:content-classes:message
X-Spam-Flag: NO
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org>
X-Virus-Checked: Checked by ClamAV on 16.mx.develooper.com
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com>
Content-Type: multipart/mixed; boundary="Boundary_(ID_8/9It0HVM/nUDvCzpSB9Tw)"
X-MS-Tnef-Correlator:
X-Spam-Score: -3.737
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 56A3D24063C for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 7 Aug 2012 12:11:56 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kri68vQQBXQO for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 7 Aug 2012 12:11:53 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 315792400C0 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 12:11:52 -0400 (EDT)
Received: (qmail 8457 invoked by uid 103); 7 Aug 2012 16:11:52 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 7 Aug 2012 16:11:52 -0000
Received: from txmx06.bankofamerica.com (HELO txdmzmailmx06.bankofamerica.com) (171.161.160.13) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Tue, 07 Aug 2012 09:11:48 -0700
Received: from txdmzmailmx07.bankofamerica.com ([171.180.168.234]) by txdmzmailmx06.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q77GBi6C024523 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 16:11:44 GMT
Received: from memtx2mta02.bankofamerica.com (memtx2mta02.bankofamerica.com [171.186.232.154]) by txdmzmailmx07.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q77GBUTE029612 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 16:11:43 GMT
X-Proofpoint-Spam-Reason: safe
Delivered-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
Return-Path: <gregory.ionis [...] baml.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-07_03:2012-08-07,2012-08-07,1970-01-01 signatures=0
X-Spam-Check-BY: 16.mx.develooper.com
X-Original-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
X-RT-Mail-Extension: dbd-odbc
Thread-Index: Ac1Zvc94Eyvic3YWSaqUmbTVksKEhwa9z/Bg
Date: Tue, 07 Aug 2012 12:11:35 -0400
X-Spam-Level:
Thread-Topic: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
X-MS-Has-Attach:
X-Mimeole: Produced By Microsoft Exchange V6.5
To: bug-DBD-ODBC [...] rt.cpan.org
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
RT-Message-ID: <rt-3.8.HEAD-9436-1344355917-1334.78186-0-0 [...] rt.cpan.org>
Content-Length: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7BIT
X-RT-Original-Encoding: utf-8
Content-Length: 5916
Download (untitled) / with headers
text/plain 5.7k
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.
Content-Description: odbc.txt
content-type: text/plain; charset="utf-8"; name="odbc.txt"
content-disposition: attachment; filename="odbc.txt"
Content-Transfer-Encoding: 7BIT
X-RT-Original-Encoding: utf-8
Content-Length: 1041
Download odbc.txt
text/plain 1k

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

Content-Description: odbc.log
content-type: application/octet-stream; name="odbc.log"
content-disposition: attachment; filename="odbc.log"
Content-Transfer-Encoding: base64
Content-Length: 15717
Download odbc.log
application/octet-stream 15.3k

Message body not shown because it is not plain text.

MIME-Version: 1.0
Content-Class: urn:content-classes:message
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -4.986
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id D01BE240642 for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 7 Aug 2012 12:14:08 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8UywpzdP+Of for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Tue, 7 Aug 2012 12:14:02 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id F327E24063E for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 12:14:01 -0400 (EDT)
Received: (qmail 8608 invoked by uid 103); 7 Aug 2012 16:14:01 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 7 Aug 2012 16:14:01 -0000
Received: from vamx02.bankofamerica.com (HELO vadmzmailmx02.bankofamerica.com) (171.159.192.79) by 16.mx.develooper.com (qpsmtpd/0.80/v0.80-19-gf52d165) with ESMTP; Tue, 07 Aug 2012 09:13:57 -0700
Received: from vadmzmailmx07.bankofamerica.com ([171.182.203.234]) by vadmzmailmx02.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q77GDr4d025495 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 16:13:53 GMT
Received: from memva2mta03.bankofamerica.com (memva2mta03.bankofamerica.com [171.186.140.81]) by vadmzmailmx07.bankofamerica.com (8.14.3/8.13.6) with ESMTP id q77GDqkh010075 for <bug-DBD-ODBC [...] rt.cpan.org>; Tue, 7 Aug 2012 16:13:53 GMT
X-Proofpoint-Spam-Reason: safe
Delivered-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-07_03:2012-08-07,2012-08-07,1970-01-01 signatures=0
X-Spam-Check-BY: 16.mx.develooper.com
Thread-Index: Ac1Zvc94Eyvic3YWSaqUmbTVksKEhwa9z/BgAACdo0A=
Date: Tue, 07 Aug 2012 12:13:49 -0400
X-Spam-Level:
X-Mimeole: Produced By Microsoft Exchange V6.5
To: bug-DBD-ODBC [...] rt.cpan.org
Content-Transfer-Encoding: 7BIT
From gregory.ionis [...] baml.com Tue Aug 7 12: 14:08 2012
X-Originalarrivaltime: 07 Aug 2012 16:13:52.0459 (UTC) FILETIME=[A2E869B0:01CD74B7]
In-Reply-To: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com>
X-Spam-Status: No, score=-4.986 tagged_above=-99.9 required=10 tests=[AWL=1.249, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com>
Message-ID: <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF8 [...] smtp_mail.bankofamerica.com>
X-MS-Tnef-Correlator:
Return-Path: <gregory.ionis [...] baml.com>
X-RT-Mail-Extension: dbd-odbc
X-Original-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
RT-Message-ID: <rt-3.8.HEAD-1087-1344356049-121.78186-0-0 [...] rt.cpan.org>
Content-Length: 6244
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.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-9436-1344355917-1334.78186-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-9436-1344355917-1334.78186-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-28102-1344504461-1670.78186-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 3810
Download (untitled) / with headers
text/plain 3.7k
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
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-28102-1344504461-1670.78186-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-9436-1344355917-1334.78186-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-28102-1344504461-1670.78186-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-16918-1354183153-1146.78186-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 4266
Download (untitled) / with headers
text/plain 4.1k
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
MIME-Version: 1.0
X-Spam-Flag: NO
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.452
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] baml.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 1E6FC240A05 for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Thu, 29 Nov 2012 08:46:07 -0500 (EST)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z77eUDgSZfnf for <cpan-bug+DBD-ODBC [...] hipster.bestpractical.com>; Thu, 29 Nov 2012 08:46:04 -0500 (EST)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 1BA5A24031C for <bug-DBD-ODBC [...] rt.cpan.org>; Thu, 29 Nov 2012 08:46:03 -0500 (EST)
Received: (qmail 22692 invoked by uid 103); 29 Nov 2012 13:46:02 -0000
Received: from x16.dev (10.0.100.26) by x1.dev with QMQP; 29 Nov 2012 13:46:02 -0000
Received: from vamx02.bankofamerica.com (HELO vadmzmailmx02.bankofamerica.com) (171.159.192.79) by 16.mx.develooper.com (qpsmtpd/0.84/v0.84-167-g4ed6cab) with ESMTP; Thu, 29 Nov 2012 05:45:58 -0800
Received: from vadmzmailmx05.bankofamerica.com ([171.182.203.230]) by vadmzmailmx02.bankofamerica.com (8.14.5/8.14.5) with ESMTP id qATDjsE4003175 for <bug-DBD-ODBC [...] rt.cpan.org>; Thu, 29 Nov 2012 13:45:54 GMT
Received: from memva2mta03.bankofamerica.com (memva2mta03.bankofamerica.com [171.186.140.81]) by vadmzmailmx05.bankofamerica.com (8.14.5/8.14.5) with ESMTP id qATDjpri007318 for <bug-DBD-ODBC [...] rt.cpan.org>; Thu, 29 Nov 2012 13:45:54 GMT
X-Proofpoint-Spam-Reason: safe
Delivered-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
Subject: RE: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8185,1.0.431,0.0.0000 definitions=2012-11-29_05:2012-11-29,2012-11-29,1970-01-01 signatures=0
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=baml.com; s=corp1210; t=1354196755; bh=f5RwBo1Mio6/AAs7kRSQY88CYczpmCUryZrQAZgTBjE=; h=Date:From:Subject:In-reply-to:To:Message-id:MIME-version: Content-type:Content-transfer-encoding:References; b=YOpzW9IV2cCjb65BQ4LkG6vomOqae/mXvKNLIbWSKUjvTr9W6AuIoUwLncu8ZKYBn 0JH5ffjrYnczsqT9/gZVDAFuHo1DFS9/oGT4WpbIs7ZJkt8DHrmbXePtgAPMXqrEz7 WGDA9H0bE67UfURhiZeO4jGvnskpeFZwPzOofeQ0=
X-Spam-Check-BY: 16.mx.develooper.com
Thread-Index: Ac3OGDOBttNOC4T6Sx+EdttgaaOSqwAH338g
Date: Thu, 29 Nov 2012 08:45:51 -0500
X-Spam-Level:
To: "'bug-DBD-ODBC [...] rt.cpan.org'" <bug-DBD-ODBC [...] rt.cpan.org>
Content-Transfer-Encoding: 7BIT
From gregory.ionis [...] baml.com Thu Nov 29 08: 46:07 2012
In-Reply-To: <rt-3.8.HEAD-16918-1354183153-848.78186-6-0 [...] rt.cpan.org>
X-Spam-Status: No, score=-5.452 tagged_above=-99.9 required=10 tests=[AWL=0.883, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-9436-1344355917-1334.78186-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-28102-1344504461-1670.78186-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-16918-1354183153-848.78186-6-0 [...] rt.cpan.org>
Content-Language: en-US
Message-ID: <28C5580DF0198841A7ED1B54BCBF86A92D8CA095 [...] smtp_mail.bankofamerica.com>
X-MS-Tnef-Correlator:
Return-Path: <gregory.ionis [...] baml.com>
X-RT-Mail-Extension: dbd-odbc
X-Original-To: cpan-bug+DBD-ODBC [...] hipster.bestpractical.com
X-MS-Has-Attach:
Thread-Topic: [rt.cpan.org #78186] Issue when DBD::ODBC upgraded from 1.24 to 1.37
Accept-Language: en-US
From: "Ionis, Gregory - RSCH AMRS" <gregory.ionis [...] baml.com>
RT-Message-ID: <rt-3.8.HEAD-28937-1354196767-113.78186-0-0 [...] rt.cpan.org>
Content-Length: 5109
Download (untitled) / with headers
text/plain 4.9k
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.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-28937-1354196767-113.78186-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <RT-Ticket-78186 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BC5A [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-21177-1341389995-122.78186-6-0 [...] rt.cpan.org> <ACF0C725BDCDCF4D8A320B6FE2598F211E17BCF7 [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-9436-1344355917-1334.78186-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-28102-1344504461-1670.78186-6-0 [...] rt.cpan.org> <rt-3.8.HEAD-16918-1354183153-848.78186-6-0 [...] rt.cpan.org> <28C5580DF0198841A7ED1B54BCBF86A92D8CA095 [...] smtp_mail.bankofamerica.com> <rt-3.8.HEAD-28937-1354196767-113.78186-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-29217-1354197457-438.78186-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 193
Download (untitled) / with headers
text/plain 193b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.