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
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.3 and AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
