[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freetds
Subject:    Re: [freetds] bp with empty char/varchar column broken
From:       "Craig A. Berry" <craigberry () mac ! com>
Date:       2014-11-21 15:43:43
Message-ID: 2FE95B42-7EA0-47EB-9D65-056C16C470CC () mac ! com
[Download RAW message or body]


> On Nov 21, 2014, at 5:58 AM, Frediano Ziglio <freddy77@gmail.com> wrote:
> 
> 2014-11-20 19:53 GMT+00:00 Craig A. Berry <craigberry@mac.com>:
> > The following worked in 0.91 but is broken as of branch-0_92-839-gd788046.  If we \
> > bulk out a table with an empty (but not NULL) char or varchar column that is less \
> > than 256 bytes long, 256 spaces get written to the output file for that column.  \
> > Which then causes an overflow error if you try to bulk it back in.
> 

> Quite strange. Why does it happen only for empty strings? Should even
> happen with small ones. The function has to pad or not based on type.

The actual length of the string received on the wire is passed as the source length \
to dbconvert, and dbconvert (usually) uses that as its return value, and that return \
value is passed to fwrite for moving data to the file.

But if the source length is zero, dbconvert uses the destination length as its return \
value as long as the destination length is greater than zero.  Since it's now always \
256, we get 256 spaces.

> Actually is not clear to me what an empty column should look like in
> the text bcp file.

I'm pretty sure a zero-length column in a bcp file indicates NULL, and one or more \
spaces indicates empty string and will be trimmed on bulk in.

________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

_______________________________________________
FreeTDS mailing list
FreeTDS@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds


[prev in list] [next in list] [prev in thread] [next in thread]