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: Stephen dot Sprague at MorganStanley dot com
Subject: Re: Sybase::CTlib implementation of BLK routines and NUMERIC() values
Date: May 18 2004 2:00PM

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

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 :