Skip Menu |

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

Report information
The Basics
Id: 54426
Status: open
Priority: 0/
Queue: DBD-Informix

People
Owner: Nobody in particular
Requestors: chrissalch [...] letu.edu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: NUM_OF_FIELDS > 0 test is broken
Date: Mon, 8 Feb 2010 18:28:09 -0600
To: <bug-DBD-Informix [...] rt.cpan.org>
From: Chris Salch <ChrisSalch [...] letu.edu>
I have a small DAO module that attempts to use the following test as a means of determining if a statement handle should be expected to return results or not (Direct quote from the perldoc): You can tell whether the statement is just executable or whether it is a cursory (fetchable) statement by testing the Informix-specific attribute ix_Fetchable. The approved, canonical DBI method of doing this check is "$sth->{NUM_OF_FIELDS} > 0". Unfortunately, this seems to return the a number greater than 0 on the test system that I have available. A look at the code shows that there are different checks for NUM_OF_FIELDS and ix_Fetchable which is expectecd. What is not expected is that the suggested test fails. The attached patch appears to fix this issue by doing the same check as is used by ix_Fetchable and returning 0 if the statement is not fetchable or the number of columns if it is. I'm not sure if there is a better way to do this or not. -- -------------------------------------------- Chris Salch Programmer/Analyst

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

From: chrissalch [...] letu.edu
I've tested this on: Perl Version 5.008008 DBI Version 1.609 DBD::Informix Version 2008.0513 IBM Informix CSDK Version 3.00, IBM Informix-ESQL Version 3.00.FC3DE and Perl Version 5.010000 DBI Version 1.607 DBD::Informix Version 2008.0513 IBM Informix CSDK Version 3.50, IBM Informix-ESQL Version 3.50.FC3DE
CC: "Guardian of DBD::Informix" <dbd.informix [...] gmail.com>, bug-DBD-Informix <bug-DBD-Informix [...] rt.cpan.org>
Subject: Re: [rt.cpan.org #54426] NUM_OF_FIELDS > 0 test is broken
Date: Tue, 9 Feb 2010 12:48:28 -0600
To: Jonathan Leffler <jonathan.leffler [...] gmail.com>
From: Chris Salch <ChrisSalch [...] letu.edu>
On Tue, 2010-02-09 at 11:16 -0600, Jonathan Leffler wrote: Show quoted text
> Thanks, Chris, for both the basic bug report along with the patch and > this extra information. > > I am looking at the test code, and there's very little that checks on > NUM_OF_FIELDS. > > Do you recall what statement(s) are returning NUM_OF_FIELDS > 0? It > is far from critical; I can probably find out easily enough. My > suspicion is INSERT - if there's anything else, it would be helpful. > > Thanks,
Well, it turns out this is beautifully esoteric. I spent the last hour or so trying to duplicate my results. It turns out that the INSERT statement appears to be the only one affected and it appears to *only* be affected when using parameterized statements. I build a small test script to attempt to duplicate my results. It should be attached. I've the patch I submitted *appears* to work in the on the systems I'm working with but has in no way been exhaustively tested. Run Without Patch: -> GOOD Check Insert (With Params)2:0 -> FAIL Check Select 3:1 -> GOOD Check Select (With Params)3:1 -> GOOD Check Update (happens) 0:0 -> GOOD Check Update (nothing to do) 0:0 -> GOOD Check Update (happens, With Params) 0:0 -> GOOD Check Update (nothing to do, With Params) 0:0 -> GOOD Check Delete (nothing to do) 0:0 -> GOOD Check Delete (happens) 0:0 -> GOOD Check Delete (nothing to do, With Params) 0:0 -> GOOD Check Execute Function 1:1 -> GOOD Check Execute Function (With Params)1:1 -> GOOD Check Execute Procedure 0:0 -> GOOD Check Execute Procedure (With Params)0:0 -> GOOD Run with Patch: Check Insert0:0 -> GOOD Check Insert (With Params)0:0 -> GOOD Check Select 3:1 -> GOOD Check Select (With Params)3:1 -> GOOD Check Update (happens) 0:0 -> GOOD Check Update (nothing to do) 0:0 -> GOOD Check Update (happens, With Params) 0:0 -> GOOD Check Update (nothing to do, With Params) 0:0 -> GOOD Check Delete (nothing to do) 0:0 -> GOOD Check Delete (happens) 0:0 -> GOOD Check Delete (nothing to do, With Params) 0:0 -> GOOD Check Execute Function 1:1 -> GOOD Check Execute Function (With Params)1:1 -> GOOD Check Execute Procedure 0:0 -> GOOD Check Execute Procedure (With Params)0:0 -> GOOD Thank you for your quick response. I was a little worried that this driver wasn't being maintained. -- -------------------------------------------- Chris Salch Programmer/Analyst LeTourneau University 903-233-3537

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

CC: "Guardian of DBD::Informix" <dbd.informix [...] gmail.com>, bug-DBD-Informix <bug-DBD-Informix [...] rt.cpan.org>
Subject: Re: [rt.cpan.org #54426] NUM_OF_FIELDS > 0 test is broken
Date: Tue, 9 Feb 2010 11:13:22 -0800
To: Chris Salch <ChrisSalch [...] letu.edu>
From: Jonathan Leffler <jonathan.leffler [...] gmail.com>
On Tue, Feb 9, 2010 at 10:48 AM, Chris Salch <ChrisSalch@letu.edu> wrote: Show quoted text
> > Well, it turns out this is beautifully esoteric. I spent the last hour > or so trying to duplicate my results. It turns out that the INSERT > statement appears to be the only one affected and it appears to *only* > be affected when using parameterized statements. I build a small test > script to attempt to duplicate my results. It should be attached. I've > the patch I submitted *appears* to work in the on the systems I'm > working with but has in no way been exhaustively tested. >
I'll get to look at this soon - thanks. And INSERT is something of a special case in the way it behaves with Informix. Things have moved on to the point where supported servers (as in, versions of IDS supported by IBM/Informix) probably all have the stuff I need to improve this code. Show quoted text
> Thank you for your quick response. I was a little worried that this > driver wasn't being maintained. >
Not actually unmaintained - just not needing much maintenance. I was expecting to have to make a release to allow for a new version of CSDK later this year; they've changed their minds about the versioning and the next version is already handled by the code (unless they do something else with the format of the messaging - which is always possible). There are a few issues that should ideally be dealt with - but they are all pretty minor, hence the absence of a bug fix since May 2008. I will make a release - 2010.0xyy - just to show that there is still life around. I just haven't formally decided on a month x, let alone a date within the month yy. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."