On Sun 20 Jan 2002 23:11, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 18, 2002 at 05:11:48PM +0100, H.Merijn Brand wrote:
> > "ChopBlanks" (boolean, inherited)
> > This attribute can be used to control the trimming of trailing
> > space characters from fixed width character (CHAR) fields. No
> > other field types are affected, even where field values have
> > trailing spaces.
> >
> > **WHY** only from fixed width character fields, and not from varchar2 fields ?
> > :((((
> >
> > We've got a multidatabase environment, in which we try *very* hard not to get
> > NULL fields - ever -. This means we have to insert triggers in Oracle to
> > inhibit it's fu**ing annoying behaviour of translating empty varchar fields to
> > NULL. (If I insert an empty string I expect an empty string, and not a null field!)
>
> That has to be one of Oracle's most annoying, er, um, 'features'.
Ahh, good to know that I'm not the only one to doubt this annoyance^Wfeature
> > The triggers translate all empty strings to a string with just a single space
> > in it on insert and update.
>
> I am open to changing my mind on this one.
>
> I'd appreciate any input from driver authors who either:
>
> a) set ChopBlanks on by default (which they probably shouldn't)
From my docs (DBD::Unify)
At the moment none of the attributes documented in DBI's "ATTRIBUTES
COMMON TO ALL HANDLES" are implemented specifically for the Unify
DBD driver, but they might have been inhereted from DBI. The
ChopBlanks attribute is implemented, but defaults to 1 for
DBD::Unify. The Unify driver supports "ScanLevel" to set the
transaction scan level to a value between 1 and 16 and "DBDverbose"
to set DBD specific debugging, allowing to show only massages from
DBD-Unify without using the default DBI->trace () call.
That might be because it looks like I'm the only one using DBD::Unify for
production databases :)
> or
> b) don't want ChopBlanks extended to VARCHAR fields
Since I use a generic module (using DBDlogon () to connect to the /current/
database) to catch the local differences in the Databases I have to use (my
personal choice would *not* include Oracle), catching this would not be a
problem if it were implemented as an option. I'd prefer it to default to all
char fields though.
> (Let's defer the issue of which _specific_ string types ChopBlanks
> should apply to for now and just consider CHAR and VARCHAR's at
> this point.)
And what are the opinions of the authors on having it also work the other way?
I mean that if ChopBlanks is used on VARCHAR fields too, I can now safely
insert a string containing only one single space into the databse to reflect
an empty string (which won't be converted to NULL). Since our company policy
is to not use NULL anywhere, I'd like to see some kind of DBI option that
translates an empty string to a string consisting of only one single space for
on insertion and updates for those databases that surprise the user with emty
string to NULL translation. (I've used triggers in Oracle now to do exactly
that)
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
