Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

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

A varchar() that gets truncated generates a warning, but the row is
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.


Michael Peppler                              Data Migrations, Inc.             
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short
or long term contract positions -