Re: problem with bound columns and fetchall_arrayref with a slice

On 04/06/13 06:22, Tim Bunce wrote:
> On Mon, Jun 03, 2013 at 10:43:20AM +0100, Martin J. Evans wrote:
>> Hi,
>>
>> I've just hit a problem with bind_col and fetchall_arrayref when a slice is used and I'm wondering how I might fix it. I'm using DBD::Oracle and setting a bind type and some attributes but as soon as a slice is used in fetchall_arrayref, DBI rebinds the columns and I lose the column type and attribute. Here is an example:
>
>> So this is how bind_col ends up being called:
>>
>> BIND COL 1 (TYPE => SQL_INTEGER, DiscardString => 1)
>> BIND COL 1 (no type (i.e. type = 0) and no attrs)
>> BIND COL 2 (no type and no attrs)
>> BIND COL 3 (no type and no attrs)
>> BIND COL 4 (no type and no attrs)
>>
>> The code in DBD::Oracle is possibly flawed in that every time bind_col is called it does:
>>
>> 	imp_sth->fbh[field-1].req_type = type;
>> 	imp_sth->fbh[field-1].bind_flags = 0; /* default to none */
>>
>> regardless of whether bind_col has been called before and set a type
>> or attributes. As type is a parameter to dbd_st_bind_col anyone not
>> wishing to set a type has to say 0.
>>
>> I could fix my usage case by simply saying if bind_col has been called
>> for a column which already has a type set and the incoming type is 0
>> don't touch it and if no attributes are passed don't clear any
>> existing ones. It would work for me but I'd like to hear any comments.
>
> I see the docs don't spell it out but I've always intended the bind_col
> type parameter to be 'sticky' - i.e. a missing or undef value wouldn't
> undo previous type settings.
>
> Feel free to patch the docs to clarify that.
>
> Tim.
>

I have updated the bind_col pod in DBI.

I've released a new DBD::ODBC which fixes the sticky issue (in DBD::ODBC TYPE was ok but attributes were not).

I've sent a pull request to Yanick to fix stickiness in DBD::Oracle.

Martin