FreeTDS Development Group

[Cedric ROUVRAIS <cedric.rouvrais AT sgcib.com>]

Hi James,

For me the question is not who is right or wrong. The question is to get as
many apps as possible off Sybase ASAP. To have a bcp and isql utility that
behaves in the same manner with the same options as the Sybase utilities is
invaluable. The decisions of the past and quality of work (or lack thereof)
that has been done by others will not prevent my from sleeping.

Once everyone is off Sybase, then we will need to look at these problematic
applications and decide what to do with them. Some of them are "legacy" in
the sense that the initial development teams are long gone and the
application hasn't evolved in decades but is still being used and renders
many services.

>From my perspective, we have until October to get every single application
off Sybase and we started in June of this year. My commitment was as lead
technical architect, for one to make it work for everyone, for two to make
it as seamless and painless as possible.

a++ Cedric



|------------------------------                                            
|            "James K. Lowden"                                             
|            <jklowden@freetds                                             
|            .org>                                                         
|            Sent by:                                                      
|            freetds-bounces@l                                             
|            ists.ibiblio.org                                              
|                                                                          
|                                                                          
|            08/24/2009 06:07                                              
|            PM                                                            
|                                                                          
|                                                                          
|            Please respond to                                             
|                 FreeTDS                                                  
|            Development Group                                             
|            <freetds AT lists.ib                                             
|               iblio.org>                                                 
|                                                                          
|                                                                          
                                                                           
                                                                           
                                                                        To 
                                               FreeTDS Development Group   
                                               <freetds AT lists.ibiblio.org> 
                                                                        cc 
                                                                           
                                                                   Subject 
                                               Re: [freetds] BCP In of     
                                               data too large fails [NC]   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Cedric ROUVRAIS wrote:
>
> If ansi warnings are set to off then the result of a bcp in should be a
> truncation when the data is to large for the destination column.  Sybase
> bcp works like this for sure, so I added the feature in freebcp.c

Microsoft's bcp.exe refuses to load a row with an overlong value
regardless of the value of ANSI warnings.  Either way, you get this
message:

  $ bcp testdb..a in a.txt -S mpquant -c -T

  Starting copy...
  SQLState = 22001, NativeError = 0
  Error = [Microsoft][ODBC SQL Server Driver]String data, right truncation

  0 rows copied.

IMO this is the correct behavior, and I see no particular advantage to
Sybase's choice.  Failure is *better*: with it, the user can edit the data
file or alter the table, and consistently finds errors in the -e error
file.  The change you propose forces the user to look (sometimes,
depending on the database option) in the output log too, and the message
doesn't bother to indicate which column is at fault.

I'm not sure full compatibility with Sybase is all that desirable for
freebcp.  For example, rather than truncating your data, wouldn't it be
better if the user could specify a "rejected row" file?  freebcp could
separate its input into to two piles: rows sent to the database, and rows
not sent, for one reason or another.  The user could peruse the .err file
(-e output) for problems, and modify & re-process the .rej file, knowing
anything not in the .rej is already in the table.

Another weakness of both the vendor and FreeTDS bcp utilities is that the
don't always return an error to the OS if any row was not loaded.  That
makes it useless for batch operations.  :-/

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds



*************************************************************************
This message and any attachments (the "message") are confidential, intended 
solely for the addressee(s), and may contain legally privileged information.  
Any unauthorised use or dissemination is prohibited.  E-mails are susceptible 
to alteration.  Neither SOCIETE GENERALE nor any of its subsidiaries or 
affiliates shall be liable for the message if altered, changed or falsified.
*************************************************************************