Ok, as I suspected, this was sort of my fault. You can indeed do:
$h = DBI->Connect;
$s = $h->prepare(q/select * from sometable/);
$s->{ChopBlanks} = 1;
and it chops blanks but you cannot do:
selectall_arrayref(q/select * from sometable/, {ChopBlanks => 1});
or
prepare(q/select * from sometable/, {ChopBlanks => 1});
Don't know if you should be able to do this but it seems you cannot. I
think it would be nice especially in the selectall methods as you do not
see the sth. I tried to locate the code to do this which I thought was
somewhere under _new_handle (probably dbih_setup_handle) but there is
magic in there I don't get right now.
Martin
On 03/01/2011 10:52, H.Merijn Brand wrote:
On Mon, 03 Jan 2011 10:27:52 +0000, "Martin J. Evans"
<martin.ev...@easysoft.com> wrote:
On 02/01/2011 18:50, H.Merijn Brand wrote:
On Sun, 02 Jan 2011 18:07:13 +0000, "Martin J. Evans"
<martin.ev...@easysoft.com> wrote:
Sorry if this turns out to be gibberish but I'm been battling with a
host of unicode problems today and I am quickly losing track.
I can't make ChopBlanks work properly in DBD::ODBC. It works if I use:
$dbh->{ChopBlanks} = 1;
$sth = $dbh->prepare (q/select * from sometable/);
and does not work if I use:
$sth = $dbh->prepare (q/select * from sometable/);
$sth->{ChopBlanks} = 1;
The above completely meets my expectation.
really. You expect ChopBlanks set directly on an sth to not work?
Damn :)
I read that as $dbh->{ChopBlanks} = 1;
Once the sth is created, and
all attributes are set (either directly or derived/inherited from dbh),
they should *not* change when dbh changes it on a higher level.
I agree that once set on a sth, a change to the dbh should not change
the sth but what I'm seeing is if they are NOT set on the dbh and then
you create an sth, you cannot change it on the sth directly. The docs
suggest ChopBlanks is for connection and statement handles.
$dbh = DBI->connect;
$sth = $dbh->prepare (q/select * from sometable/);
$sth->{ChopBlanks} = 1
now DBIc_has (imp_sth, DBIcf_ChopBlanks) returns false.
I fully agree that this sounds like unwanted behavior.
and it seems "ChopBlanks = DBIc_has (imp_sth, DBIcf_ChopBlanks);" is not
true in DBD::ODBC's dbdimp.c.
Various DBD's use DBIc_has (DBD::ODBC, DBD::Pg, DBD::Oracle) or DBIc_is
(DBD::mysql).
DBD::Unify uses DBIc_has ()
DBD::CSV (through DBD::File) use s DBIc_is ()
In fact they are the same:
DBIXS.h:#define DBIc_has(imp,flag) DBIc_is(imp, flag) /* alias for DBIc_is */
Should have looked - sorry, I did warn you I'm stuck in a world or pain
with unicode right now.
I know the pain, and I'm not pointing fingers, just passing on info
The DBI::DBD documentation says (for XS):
"Note that you can also obtain standard attributes such as /AutoCommit/
and /ChopBlanks/ from the attributes parameter, using
|DBD_ATTRIB_GET_IV| for integer attributes."
and
"The dbd_db_STORE_attrib method
You do not handle all attributes; on the contrary, you should not handle
DBI attributes here: leave this to DBI. (There are two exceptions,
/AutoCommit/ and /ChopBlanks/, which you should care about.)"
I presumed a DBD should "care" about ChopBlanks as DBI is not going to
remove the trailing blanks not that DBI is not going to store the
ChopBlanks value and yet when I call DBIc_has(imp_sth, DBIcf_ChopBlanks)
on a sth it returns false even though I set $sth->{ChopBlanks} = 1.
Before or after the sth was created?
Example above, after.
DBD::ODBC (like all the other DBDs I've checked) does not handle
ChopBlanks in the STORE or FETCH routines.
Any ideas what is wrong?
I may be making a mistake here, and may be ChopBlanks cannot be set on a
sth, but in that case the docs are confusing.
I think it should be possible, at least it would be very DWIMmish
