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 2:07PM

On Tue, 2004-05-18 at 16:00, wrote:
> my selfish angle is that any  errors/messages  that  are  agreed  to  be
> generated come though via the signal handlers.   Having them just go to
> stderr/stdout make things a tad rough to programitically catch and field.
> not sure how to do this  with  messages  generated  on  the  client  via
> cs_convert().

AFAIK conversion errors generated in cs_convert() should go to the
client callback handler, so you should be able to catch them there.


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