PEPPLER.ORG
Michael Peppler
Sybase Consulting
Menu
Home
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
Freeware
Sybperl
Sybase::Simple
DBD::Sybase
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
FAQs
Sybase on Linux FAQ
Sybperl FAQ
Personal
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
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