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
