db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <ma...@Remulak.Net>
Subject Re: Truncation error w/ INSERT stmt using blob concatenation...
Date Mon, 17 Jan 2005 22:28:15 GMT
Lynh,

It might be an unrelated problem from a quick look. The Jira entry for bug 121 says it is
a
problem under Network Server (only?). What Army has reported is for embedded Derby.
My guess is that Army's concatenation issue would be reproducible under Network Server too.

Mamta

Lynh Nguyen wrote:

> 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