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

On Tue, 2004-05-18 at 16:00, Stephen.Sprague@MorganStanley.com 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.

Michael

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