Re: BCP In of data too large fails [NC]
Cedric ROUVRAIS <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <OF0D667B4B.A76A9F5A-ON8525761C.0079F861-8525761C.007A7784@us.world.socgen> |
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 | <[email protected] | iblio.org> | | To FreeTDS Development Group <[email protected]> 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 [email protected] 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. *************************************************************************