Skip Menu |

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

Report information
The Basics
Id: 39841
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: Bruce.Tanner [...] Cerritos.edu
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 1.17
Fixed in: 1.17_1

Attachments
build_schema.pl
PS_CLASS_ASSOC.txt
PS_CLASS_ATTENDANCE.txt
PS_CLASS_ATTRIBUTE.txt
PS_CLASS_INSTR.txt
PS_CLASS_MTG_PAT.txt
PS_CLASS_TBL.txt
PS_CRSE_CATALOG.txt
PS_CRSE_COMPONENT.txt
PS_EMAIL_ADDRESSES.txt
PS_NAMES.txt
PS_PERSON.txt
PS_PERSON_NAME.txt
PS_PERSON_PHONE.txt
PS_PERSONAL_PHONE.txt
PS_STDNT_ENRL.txt
PS_STDNT_INCOMPLTE.txt
PS_TERM_TBL.txt
PSXLATITEM.txt
test.log
test.pl
test_empty_1.16.log
test_fail.log
test_failing.pl
test_working.pl
XPS_CER_ROS_SCH_VW.txt
XPS_CER_ROS_STD_VW.txt



Subject: SQL Server error with DBD::ODBC 1.17
The sub-select in test_failing.pl gives the error "String data, right truncation". c:\>test_failing.pl Using DBI 1.607 and DBD::ODBC 1.17 DB = DBI:ODBC:driver={SQL Server};Server=SQLVS2;Database=CS90PRD DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver]String data, right truncation (SQL-22001) at c:\test_failing.pl line 44. The program works correctly with DBD::ODBC 1.16. c:\>test_failing.pl Using DBI 1.607 and DBD::ODBC 1.16 DB = DBI:ODBC:driver={SQL Server};Server=SQLVS2;Database=CS90PRD Count = 4218 If I change the where clause on the sub-select, it works: c:\>test_working.pl Using DBI 1.607 and DBD::ODBC 1.17 DB = DBI:ODBC:driver={SQL Server};Server=SQLVS2;Database=CS90PRD Count = 4218 c:\>fc test_working.pl test_failing.pl Comparing files test_working.pl and TEST_FAILING.PL ***** test_working.pl AND R.CLASS_NBR = S.CLASS_NBR ) FROM ***** TEST_FAILING.PL AND R.CLASS_NBR = S.CLASS_NBR AND R.STDNT_ENRL_STATUS = 'E' AND R.CRSE_GRADE_OFF <> 'W' AND R.GRADING_BASIS_ENRL <> 'AUD' ) FROM ***** The target database is SQL Server 9.0.3042 (Microsoft SQL Server 2005 Service Pack 2). This is perl, v5.8.8 built for MSWin32-x86-multi-thread (with 12 registered patches, see perl -V for more detail) Copyright 1987-2007, Larry Wall Binary build 824 [287188] provided by ActiveState http://www.ActiveState.com Built Sep 3 2008 11:14:55 This is under Windows Server 2003 R2.
Subject: test_working.pl
use strict; use warnings; use DBI; use Rosters2::Globals; my $college = 'CER90'; my $dbh = DBI->connect( $config{$college}->{db}, $config{$college}->{login}, $config{$college}->{password}, {RaiseError=>1,PrintError=>0} ) or croak( "Can't connect to PSDB: $DBI::errstr" ); print "Using DBI $DBI::VERSION and DBD::ODBC $DBD::ODBC::VERSION\n"; print "DB = $config{$college}->{db}\n"; my $classes_sql = q{ SELECT S.CLASS_NBR, (SELECT COUNT(R.EMPLID) FROM PS_CER_ROS_STD_VW AS R WHERE R.STRM = S.STRM AND R.CLASS_NBR = S.CLASS_NBR ) FROM PS_CER_ROS_SCH_VW AS S WHERE S.STRM = ? }; my $term_code = 1089; #print "Execute $DBI::VERSION $classes_sql with $term_code\n" ; my $classes = $dbh->prepare( $classes_sql ); $classes->execute( $term_code ); my $count = 0; MEETING: while (my ( $class_nbr, $enrl_tot ) = $classes->fetchrow_array ) { $count++; } print "Count = $count";
Subject: test_failing.pl
use strict; use warnings; use DBI; use Rosters2::Globals; my $college = 'CER90'; my $dbh = DBI->connect( $config{$college}->{db}, $config{$college}->{login}, $config{$college}->{password}, {RaiseError=>1,PrintError=>0} ) or croak( "Can't connect to PSDB: $DBI::errstr" ); print "Using DBI $DBI::VERSION and DBD::ODBC $DBD::ODBC::VERSION\n"; print "DB = $config{$college}->{db}\n"; my $classes_sql = q{ SELECT S.CLASS_NBR, (SELECT COUNT(R.EMPLID) FROM PS_CER_ROS_STD_VW AS R WHERE R.STRM = S.STRM AND R.CLASS_NBR = S.CLASS_NBR AND R.STDNT_ENRL_STATUS = 'E' AND R.CRSE_GRADE_OFF <> 'W' AND R.GRADING_BASIS_ENRL <> 'AUD' ) FROM PS_CER_ROS_SCH_VW AS S WHERE S.STRM = ? }; my $term_code = 1089; #print "Execute $DBI::VERSION $classes_sql with $term_code\n" ; my $classes = $dbh->prepare( $classes_sql ); $classes->execute( $term_code ); my $count = 0; MEETING: while (my ( $class_nbr, $enrl_tot ) = $classes->fetchrow_array ) { $count++; } print "Count = $count";
Is there any chance you could reduce this down to a standalone example that creates the schema, sample row(s) and select which fails in 1.17? I realise this is asking a lot but the differences between 1.16 and 1.17 are HUGE and without knowing the schema and which column it is truncating on it is very difficult to track this down. Martin -- Martin J. Evans Wetherby, UK
On Mon Oct 06 13:47:11 2008, MJEVANS wrote: Show quoted text
> Is there any chance you could reduce this down to a standalone example > that creates the schema, sample row(s) and select which fails in 1.17? I > realise this is asking a lot but the differences between 1.16 and 1.17 > are HUGE and without knowing the schema and which column it is > truncating on it is very difficult to track this down. > > Martin
If this is just not possible if you could run it in 1.16 and 1.17 with DBI_TRACE set to 15 and odbcunicode and odbcconnection flags turned on in 1.17 - see <a href="http://search.cpan.org/~mjevans/DBD-ODBC-1.17/ODBC.pm#Tracing">tracing</a> and in particular <code> use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode')); </code> but that bit only applies to 1.17 and DBI 1.607. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17
Date: Mon, 6 Oct 2008 11:16:43 -0700
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Tanner, Bruce" <Bruce.Tanner [...] Cerritos.edu>
I was afraid you would ask something like that. The views apply to our PeopleSoft ERP database which is huge. I would have to try and create a standalone collection of equivalent tables. It's possible, but will take a while... I've enclosed the trace. -Bruce -- Bruce Tanner (562) 860-2451 x 2164 Bruce.Tanner@Cerritos.edu Cerritos College Norwalk, CA Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Monday, October 06, 2008 10:52 AM To: Tanner, Bruce Subject: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17 <URL: http://rt.cpan.org/Ticket/Display.html?id=39841 > On Mon Oct 06 13:47:11 2008, MJEVANS wrote:
> Is there any chance you could reduce this down to a standalone example > that creates the schema, sample row(s) and select which fails in 1.17? I > realise this is asking a lot but the differences between 1.16 and 1.17 > are HUGE and without knowing the schema and which column it is > truncating on it is very difficult to track this down. > > Martin
If this is just not possible if you could run it in 1.16 and 1.17 with DBI_TRACE set to 15 and odbcunicode and odbcconnection flags turned on in 1.17 - see <a href="http://search.cpan.org/~mjevans/DBD-ODBC-1.17/ODBC.pm#Tracing">tracing</a> and in particular <code> use DBD::ODBC; DBI->trace(DBD::ODBC->parse_trace_flags('odbcconnection|odbcunicode')); </code> but that bit only applies to 1.17 and DBI 1.607. Martin -- Martin J. Evans Wetherby, UK
Download test_fail.log
application/octet-stream 18.2k

Message body not shown because it is not plain text.

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

Thanks for the trace. I'll look thru it tonight and tomorrow as it is getting late here. As you will have guessed it is a lot easier if I can reproduce here as I don't have to bother you with repeated requests to run with different tracing but I might be able to work it out from the trace so hold on with reducing it further. What might help that you could do reasonably easily is to send me a list of the database column types for the select list (especially if any is unicode - nvarchar etc). Did you build DBD::ODBC as the default i.e., did you add anything to the perl Makefile.PL commnand line? Have you tried rebuilding DBD::ODBC with the "-nou" switch which disables extensive unicode support? Will get back to you later. -- Martin J. Evans Wetherby, UK
get_param_type 1 SQLDescribeParam 1: SqlType=VARCHAR param_size=3 Scale=0 Nullable=0 -> dbd_st_execute -> dbd_st_finish dbd_st_execute (outparams = 0)... bind 1 '1089' (size svCUR=4/SvLEN=8/max=0) svtype 5, value type:1 sql type:12 get_param_type 1 SQLDescribeParam already run and returned rc=0 bind 1 '1089' value_len:4 maxlen:6 null:0) bind 1 value_type:1 VARCHAR cs=3 dd=0 bl:4. SQLBindParameter: idx = 1: param_type=1, name=1, value_type=1, SQL_Type = 12, column_size=3, d_digits=0, value_ptr=1ab8aec, buffer_length=4, cbValue = 4, param_size = 3 Param value = 1089 rebind check char Param 1 (1089... ) dbd_st_execute (for hstmt 1b22178, rc = -1) Forget the column types - it is failing on the execute and the above looks suspicious as the parameter value is "1089" but the param_size is 3! What is S.STRM? Can you run the working versions and look for the above tracing to see how it compares. For 1.16 you'll have to leave off the odbcunicode and odbcconnection flags or ignore them erroring. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17
Date: Mon, 6 Oct 2008 14:55:26 -0700
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Tanner, Bruce" <Bruce.Tanner [...] Cerritos.edu>
Hello Martin, Here's a program to build the schema from the table/view definitions. I created an empty database manually first. It appears that you don't need any data to trigger the error. c:\test>build_schema.pl Processing PSXLATITEM.txt Processing PS_CLASS_ASSOC.txt Processing PS_CLASS_ATTENDANCE.txt Processing PS_CLASS_ATTRIBUTE.txt Processing PS_CLASS_INSTR.txt Processing PS_CLASS_MTG_PAT.txt Processing PS_CLASS_TBL.txt Processing PS_CRSE_CATALOG.txt Processing PS_CRSE_COMPONENT.txt Processing PS_EMAIL_ADDRESSES.txt Processing PS_NAMES.txt Processing PS_PERSON.txt Processing PS_PERSONAL_PHONE.txt Processing PS_PERSON_NAME.txt Processing PS_PERSON_PHONE.txt Processing PS_STDNT_ENRL.txt Processing PS_STDNT_INCOMPLTE.txt Processing PS_TERM_TBL.txt Processing XPS_CER_ROS_SCH_VW.txt Processing XPS_CER_ROS_STD_VW.txt c:\test>test.pl DBI 1.607-ithread default trace level set to 0x0/15 (pid 3996) at test.pl line 6 dbd_db_login6 SQLDriverConnect 'driver={SQL Server};Server=avm01;Database=Bruce_test;UID=;PWD=;', '', 'xxxx' Out connection string: DRIVER=SQL Server;SERVER=avm01;UID=console;PWD=;APP=ActivePerl;WSID=AVM17;DATABASE=Bruce_test;Trusted_Connection=Yes Turning autocommit on DRIVER_ODBC_VER = 03.52 DRIVER_NAME = SQLSRV32.DLL DRIVER_VERSION = 03.86.3959 MAX_COLUMN_NAME_LEN = 128 DBD::ODBC is unicode built : YES SQL_DBMS_NAME = Microsoft SQL Server SQLMoreResults supported: 1 SQLDescribeParam supported: 1 Using DBI 1.607 and DBD::ODBC 1.17 Processing non-utf8 sql in unicode mode DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver]String data, right truncation (SQL-22001) at c:\test\test.pl line 42. SQLDisconnect=0 -Bruce -- Bruce Tanner (562) 860-2451 x 2164 Bruce.Tanner@Cerritos.edu Cerritos College Norwalk, CA Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Monday, October 06, 2008 10:52 AM To: Tanner, Bruce Subject: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17 <URL: http://rt.cpan.org/Ticket/Display.html?id=39841 > On Mon Oct 06 13:47:11 2008, MJEVANS wrote:
> Is there any chance you could reduce this down to a standalone example > that creates the schema, sample row(s) and select which fails in 1.17? I > realise this is asking a lot but the differences between 1.16 and 1.17 > are HUGE and without knowing the schema and which column it is > truncating on it is very difficult to track this down. > > Martin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Well I asked for that - didn't I. Don't hold your breath ;-) Get back to you when I've set this up. In the mean time if you manage to run 1.16 with full tracing and pinpoint the tracing in my previous response it may be useful but I'll get on to this tomorrow. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17
Date: Mon, 6 Oct 2008 16:08:00 -0700
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Tanner, Bruce" <Bruce.Tanner [...] Cerritos.edu>
Hello Martin, I was working on the table extraction/creation project and didn't get back to looking at email until after I sent off my last message. It looks like we got out of synch a bit. Here is a successful trace with both the production database and the empty test database with 1.16. I selected TOP 2 to save going through 4000 class records. c:\test>test.pl 2> test.log Using DBI 1.607 and DBD::ODBC 1.16 Count = 2 c:\test>test.pl 2> test_empty_1.16.log Using DBI 1.607 and DBD::ODBC 1.16 Count = 0 STRM is the term identifier, I don't know what the S is there for. The format is YYYM, 108 is 1900 + 108 (yes, it is a y2k thing) and 9 is September (for the fall semester), so 1089 is Fall 2008. DBD::ODBC is from the ActiveState archive. I've never gotten into the habit of compiling my own modules, but it should be possible after I gather up all of the tools needed. -Bruce -- Bruce Tanner (562) 860-2451 x 2164 Bruce.Tanner@Cerritos.edu Cerritos College Norwalk, CA Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Monday, October 06, 2008 3:13 PM To: Tanner, Bruce Subject: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17 <URL: http://rt.cpan.org/Ticket/Display.html?id=39841 > Well I asked for that - didn't I. Don't hold your breath ;-) Get back to you when I've set this up. In the mean time if you manage to run 1.16 with full tracing and pinpoint the tracing in my previous response it may be useful but I'll get on to this tomorrow. Martin -- Martin J. Evans Wetherby, UK
Download test.log
application/octet-stream 20.6k

Message body not shown because it is not plain text.

Download test_empty_1.16.log
application/octet-stream 19.8k

Message body not shown because it is not plain text.

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

Bruce, I'm nearly there. I can see why it is failing but not as yet why SQL Server returns 3 for the strm size. I appear to be missing a couple of text files for the tables PS_CER_ROS_SCH_VW and PS_CER_ROS_SCH_VW.txt. They show in your log of running build_schema.pl as files prefixed with X but I have not got them. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17
Date: Tue, 7 Oct 2008 08:01:50 -0700
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Tanner, Bruce" <Bruce.Tanner [...] Cerritos.edu>
I must have missed them when I sent everything off. They have the X to put them at the end since they rely on all of the other tables to be there first. -Bruce Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Tuesday, October 07, 2008 1:56 AM To: Tanner, Bruce Subject: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17 <URL: http://rt.cpan.org/Ticket/Display.html?id=39841 > Bruce, I'm nearly there. I can see why it is failing but not as yet why SQL Server returns 3 for the strm size. I appear to be missing a couple of text files for the tables PS_CER_ROS_SCH_VW and PS_CER_ROS_SCH_VW.txt. They show in your log of running build_schema.pl as files prefixed with X but I have not got them. Martin -- Martin J. Evans Wetherby, UK

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

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

On Tue Oct 07 11:02:07 2008, Bruce.Tanner@Cerritos.edu wrote: Show quoted text
> I must have missed them when I sent everything off. They have the X > to put them at the end since they rely on all of the other tables to > be there first.
Thanks. Martin -- Martin J. Evans Wetherby, UK
Sorry to be a pain but I'm still missing: Invalid object name 'PSXLATITEM' referred to in XPS_CER_ROS_SCH_VW.txt. Just to give you hope, I think I have identified the issue and it is a bug in the SQL Server ODBC driver but I also think I have a workaround. Just want to check in your case as the problem is that when you call SQLDescribeParam in ODBC, SQL Server analyses your SQL and attempts to turn it into a select statement on the tables/views to get parameter info. Your sql has 2 selects and it is difficult to guess how sql server is turning that into a select to obtain the STRM parameter. Martin -- Martin J. Evans Wetherby, UK
Subject: RE: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17
Date: Tue, 7 Oct 2008 09:02:42 -0700
To: "bug-DBD-ODBC [...] rt.cpan.org" <bug-DBD-ODBC [...] rt.cpan.org>
From: "Tanner, Bruce" <Bruce.Tanner [...] Cerritos.edu>
Some days I can't do anything right. -Bruce Show quoted text
-----Original Message----- From: Martin J Evans via RT [mailto:bug-DBD-ODBC@rt.cpan.org] Sent: Tuesday, October 07, 2008 8:22 AM To: Tanner, Bruce Subject: [rt.cpan.org #39841] SQL Server error with DBD::ODBC 1.17 <URL: http://rt.cpan.org/Ticket/Display.html?id=39841 > Sorry to be a pain but I'm still missing: Invalid object name 'PSXLATITEM' referred to in XPS_CER_ROS_SCH_VW.txt. Just to give you hope, I think I have identified the issue and it is a bug in the SQL Server ODBC driver but I also think I have a workaround. Just want to check in your case as the problem is that when you call SQLDescribeParam in ODBC, SQL Server analyses your SQL and attempts to turn it into a select statement on the tables/views to get parameter info. Your sql has 2 selects and it is difficult to guess how sql server is turning that into a select to obtain the STRM parameter. Martin -- Martin J. Evans Wetherby, UK

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

Bruce, I've found the problem and it is a bug in the SQL Server ODBC driver. When you call SQLDescribeParam the driver scans your SQL and attempts to rearrange it into a simple query where 1 = 0 to find out the column details. For your SQL (which fails) the driver ends up running: select R.GRADING_BASIS_ENRL from PS_CER_ROS_STD_VW AS R where 1=2 which returns 3 for the size of grading_basis_enrl. and in the working case where you removed some columns from the where clause it runs: select R.CLASS_NBR from PS_CER_ROS_STD_VW AS R where 1=2 which also entirely wrong but by accident returns a number >= 4 so it works - by accident. Why does this differ in 1.16? The reason is that 1.16 called SQLDescribeParam but ignored the returned parameter size if it was < 80 and set the column size in the SQLBindParameter call to 80. This was wrong in DBD::ODBC, it caused some problems and I fixed it not realising it would hit this bug in the SQL Server ODBC Driver. A workaround for this bug in SQL Server ODBC Driver is possible and not totally illogical. If the parameter is a VARCHAR and the size of the parameter you are passing is > the column_size returned from SQLDescribeParam then the driver is broken and bound to error when we execute. A simple solution is to bump the column_size to at least the size of the parameter about to be bound if the column_size is smaller and it is a VARCHAR. I've done this change and verified it works in your case but you should realise it is a workaround for a bug in the SQL Server ODBC Driver. It is also possible that if you prepare and bind parameters but re-execute it with different sized parameters it may not work but I'll check this later. I only wish I had access to MS to report this problem so it could be fixed but I don't - the last few problems I reported on MS news groups were acknowledged as bugs by MS but have never been fixed to my knowledge. In the mean time I've mailed a workaround version of DBD::ODBC to your email address privately but this may only be the start of your problems since you are using active state. I've struggled in the past to build perl XS modules for activestate perl - they compile and link but sometimes fail to work - it seems you need to match activestates builds environment very closely - same versions of compilers etc. In theory, if you have MS dev studio you should be able to go to start menu, programs and select the developer studio menu item that starts a command prompt with the developer studio environment set. You then unpack DBD::ODBC and do the "perl Makefile.PL" followed by nmake (optionally nmake test) and "nmake install". If you do the "nmake test" you'll need to: set DBI_DSN=dbi:ODBC:mydsn set DBI_USER=my_sql_server_username set DBI_PASS=my_sql_server_password first. Best of luck. If I can help you get the new version built I will just let me know. Martin -- Martin J. Evans Wetherby, UK
I believe this is now fixed in DBD::ODBC 1.17 and I will be creating a test case for it later today.
From: Scott.Stricker [...] NGC.com
On Wed Oct 08 06:08:54 2008, MJEVANS wrote: Show quoted text
> I believe this is now fixed in DBD::ODBC 1.17 and I will be creating a > test case for it later today.
For whatever it's worth, I've worked around the problem by adding the following lines to my perl code which is erroring out. Have not tried one line vs. the other, but with both I don't get the truncate error. $dbh->{LongReadLen} = 20000; $dbh->{LongTruncOk} = 1; Note that the table I've used which causes the error only has varchar and numeric columns so I was surprised that this fixed the error.
On Wed Oct 08 09:30:32 2008, stricsc wrote: Show quoted text
> For whatever it's worth, I've worked around the problem by adding the > following lines to my perl code which is erroring out. Have not tried > one line vs. the other, but with both I don't get the truncate error. > > $dbh->{LongReadLen} = 20000; > $dbh->{LongTruncOk} = 1; > > Note that the table I've used which causes the error only has varchar > and numeric columns so I was surprised that this fixed the error. > >
I seriously doubt you are talking about the same problem. The issue found is a bug in the SQL Server ODBC Driver and totally unaffected by setting LongReadLen or LongTrucOk which ONLY apply to retrieved data and not the input bound parameters this bug is about. Martin -- Martin J. Evans Wetherby, UK
From: Scott.Stricker [...] NGC.com
On Wed Oct 08 09:35:30 2008, MJEVANS wrote: Show quoted text
> On Wed Oct 08 09:30:32 2008, stricsc wrote:
> > For whatever it's worth, I've worked around the problem by adding the > > following lines to my perl code which is erroring out. Have not tried > > one line vs. the other, but with both I don't get the truncate error. > > > > $dbh->{LongReadLen} = 20000; > > $dbh->{LongTruncOk} = 1; > > > > Note that the table I've used which causes the error only has varchar > > and numeric columns so I was surprised that this fixed the error. > > > >
> > I seriously doubt you are talking about the same problem. The issue > found is a bug in the SQL Server ODBC Driver and totally unaffected by > setting LongReadLen or LongTrucOk which ONLY apply to retrieved data and > not the input bound parameters this bug is about. > > Martin
Very possibly so. I do know that if I am using the latest Activestate perl dist for Windows XP updated with the 1.17 dbd-odbc module against my SQL Server database, I get the truncate error. If I add the lines listed above the error goes away. I don't get the error with the 1.16 version of the odbc module or if I talk to the database with, for example, the DBD-ADO module.
On Wed Oct 08 10:44:39 2008, stricsc wrote: Show quoted text
> On Wed Oct 08 09:35:30 2008, MJEVANS wrote:
> > On Wed Oct 08 09:30:32 2008, stricsc wrote:
> > > For whatever it's worth, I've worked around the problem by adding the > > > following lines to my perl code which is erroring out. Have not
tried Show quoted text
> > > one line vs. the other, but with both I don't get the truncate error. > > > > > > $dbh->{LongReadLen} = 20000; > > > $dbh->{LongTruncOk} = 1; > > > > > > Note that the table I've used which causes the error only has varchar > > > and numeric columns so I was surprised that this fixed the error. > > > > > >
> > > > I seriously doubt you are talking about the same problem. The issue > > found is a bug in the SQL Server ODBC Driver and totally unaffected by > > setting LongReadLen or LongTrucOk which ONLY apply to retrieved data and > > not the input bound parameters this bug is about. > > > > Martin
> > Very possibly so. I do know that if I am using the latest Activestate > perl dist for Windows XP updated with the 1.17 dbd-odbc module against > my SQL Server database, I get the truncate error. If I add the lines > listed above the error goes away. I don't get the error with the 1.16 > version of the odbc module or if I talk to the database with, for > example, the DBD-ADO module.
If you are saying you have a perl script which runs correctly with DBD::ODBC 1.16 but gets a truncate error with DBD::ODBC 1.17 (using the same ODBC driver) and it is fixed by setting LongReadLen or LongTruncOk) then would you be prepared to open a new rt and post the details of the script and schema so I may reproduce and fix this issue. Martin -- Martin J. Evans Wetherby, UK
From: Scott.Stricker [...] NGC.com
On Wed Oct 08 11:07:56 2008, MJEVANS wrote: Show quoted text
> On Wed Oct 08 10:44:39 2008, stricsc wrote:
> > On Wed Oct 08 09:35:30 2008, MJEVANS wrote:
> > > On Wed Oct 08 09:30:32 2008, stricsc wrote:
> > > > For whatever it's worth, I've worked around the problem by
adding the Show quoted text
> > > > following lines to my perl code which is erroring out. Have not
> tried
> > > > one line vs. the other, but with both I don't get the truncate
error. Show quoted text
> > > > > > > > $dbh->{LongReadLen} = 20000; > > > > $dbh->{LongTruncOk} = 1; > > > > > > > > Note that the table I've used which causes the error only has
varchar Show quoted text
> > > > and numeric columns so I was surprised that this fixed the error. > > > > > > > >
> > > > > > I seriously doubt you are talking about the same problem. The issue > > > found is a bug in the SQL Server ODBC Driver and totally unaffected by > > > setting LongReadLen or LongTrucOk which ONLY apply to retrieved
data and Show quoted text
> > > not the input bound parameters this bug is about. > > > > > > Martin
> > > > Very possibly so. I do know that if I am using the latest Activestate > > perl dist for Windows XP updated with the 1.17 dbd-odbc module against > > my SQL Server database, I get the truncate error. If I add the lines > > listed above the error goes away. I don't get the error with the 1.16 > > version of the odbc module or if I talk to the database with, for > > example, the DBD-ADO module.
> > If you are saying you have a perl script which runs correctly with > DBD::ODBC 1.16 but gets a truncate error with DBD::ODBC 1.17 (using the > same ODBC driver) and it is fixed by setting LongReadLen or LongTruncOk) > then would you be prepared to open a new rt and post the details of the > script and schema so I may reproduce and fix this issue. > > Martin
Martin - I've created rt 39897 with info. Let me know if you need more info than I've posted and I'll try to get it to you. Thanks...