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: 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
cs_convert().








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 :