db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lynh Nguyen <lyn...@Remulak.Net>
Subject Re: Truncation error w/ INSERT stmt using blob concatenation...
Date Mon, 17 Jan 2005 22:19:57 GMT
Hi,

I submitted a bug in Jira system and wonder if this problem is related.

http://issues.apache.org/jira/browse/DERBY-121

Regards,
Lynh Nguyen

Satheesh Bandaram wrote:

> I suspect Derby is promoting Blob || Blob to a VARCHAR FOR BIT DATA. I 
> added the following two lines to SQLBinary.java:
>
>     System.out.println("declaredLength = "+declaredLength);
>     System.out.println("ClassName = "+((Class)this.getClass()).getName());
>
> When I run the code provided by Army, I got:
>     declaredLength = 32672
>     ClassName = org.apache.derby.iapi.types.SQLVarbit
>
> But, if I insert only a ?, then the results are correct:
>     declaredLength = 102400
>     ClassName = org.apache.derby.iapi.types.SQLBlob
>
> So, I suspect the CONCAT is messing it up...
>
> Satheesh
>
> Daniel John Debrunner wrote:
>
>> Army wrote:
>
>>
>
>> >I've come across the following behavior with the Derby engine.
> It seems
>
>> >like a bug to me, but I thought I'd check to make sure it's
> not "working
>
>> >as designed" before filing a JIRA entry.
>
>>
>
>> >If I create a table with a large blob column (say 100K), and
> then I try
>
>> >to insert a CONCATENATED blob value into the table, where one
> of the
>
>> >blobs to be concatenated is larger than 32672 bytes, I get a
> truncation
>
>> >error, even though the blob column is large enough to hold the
> value
>
>> >without truncation.
>
>>
>
>>
>
>> [ code, stack trace omitted]
>
>>
>
>> >This is where my uncertainty begins. It seems to me that, in
> the above
>
>> >reproduction, "the declared length" would be 100K and the
> length of the
>
>> >host variable would be 32700. In that case, since 32700 <
> 100K, this
>
>> >should be a valid insertion. But since the variable is
> rejected, either
>
>> >1) I'm misinterpreting what the "declared length" is, or 2)
> the declared
>
>> >length is not being calculated correctly (it's being set to
> 32672 when
>
>> >it _should_ be 100K).
>
>>
>
>>
>
>>
>
>> I think the issue/bug is that the contactenated operator is
> resulting in
>
>> a type of VARCHAR(32762) FOR BIT DATA, not BLOB. Or maybe the type
> of
>
>> the ? is mapped to VARCHAR(32762) FOR BIT DATA. I wonder what the
> type
>
>> of the ? parameter should be with your statement?
>
>>
>
>> >Note that this "checkHostVariable" method is called for Blobs,
> but is
>
>> >NOT called for Clobs. Thus, if I try to do the exact same
> thing using
>
>> >clobs instead of blobs (with characters instead of bytes, of
> course),
>
>> >everything works fine.
>
>>
>
>>
>
>> The difference it there to match DB2's JCC driver. Basically
>
>> checkHostVariable() is a check in additional to normalization.
>
>> Column assignment always goes through normalization to ensure the
> value
>
>> is legitimate. Normalization rules allow truncation of pad
> characters
>
>> (0x20) when setting a value. DB2's JCC driver does not allow any
>
>> truncation of binary values from a host variable.
>
>>
>
>> E.g.
>
>>
>
>> 'abc ' is valid for VARCHAR(3)
>
>> 'abcd ' is not valid for VARCHAR(3)
>
>>
>
>> X'abcdef2020' is valid for VARCHAR(3) FOR BIT DATA (padded with two
>
>> bytes) *except* when it is a host variable (set by a parameter
> marker).
>
>>
>
>> Dan.
>


Mime
View raw message