|
|
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 :
|
