|
|
sybperl-l Archive
Up Prev Next
From: Michael Peppler <mpeppler at peppler dot org>
Subject: Re: Sybase::CTlib implementation of BLK routines and NUMERIC()
values
Date: May 18 2004 1:38PM
On Tue, 2004-05-18 at 15:01, Scott Zetlan wrote:
> Michael Peppler wrote on 5/18/2004, 8:42 AM:
> > This leads me to think that the new behavior is the right one - if the
> > data getting loaded doesn't fit the row shouldn't be allowed to go
> > through.
> >
> > I'd like to hear from those of you that use the blk_xxx() API to see
> > what the consensus on this issue is.
>
> I think Sybase is wrong on this one. The default behavior should be
> to load the data and produce a warning. Sybase::CTlib's
> implementation (and thus Sybase::BLK's) should use that as it's
> default position, and should provide an option to either suppress that
> warning or escalate it to a failure.
>
> There are numerous other instances where Sybase automatically attempts
> to convert datatypes during bulk load: strings to dates, numeric to
> float, etc. In those cases, there's only a failure if the conversion
> fails, and the conversion can succeed despite a potential loss of
> range or precision.
I tested this (still with the bcp binary), and the behavior is indeed
inconsistent:
A varchar() that gets truncated generates a warning, but the row is
loaded.
A numeric() that fails the conversion generates an error.
The bcp binary calls cs_convert() to convert the data between the format
in the bcp file and the target column(s). In the case of blk_rowxfer()
in Sybase::CTlib I actually send the data to the BLK API in char format
and let the library make the conversion as needed.
In OCS 12.5.1 ESD #1 and earlier the 123.456 value is *truncated* to
123.45. Strings that exceed the size of the target column (varchar) are
simply truncated, with no warning.
So now the question is - does Sybase::CTlib need to make better checking
of the compatibility of the source data and the target columns for
blk_rowxfer() calls?
> In any case, Sybase::CTlib and Sybase::BLK should be flexible on this
> point and allow the programmer to override Sybase's default behavior
> as needed.
Noted.
Michael
--
Michael Peppler Data Migrations, Inc.
mpeppler@peppler.org http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short
or long term contract positions - http://www.peppler.org/resume.html
|
