|
I have a long binary field in an Android UltraliteJ database and when I insert a value into it the byte array is around 800-900K in length. However, when I select it out it's less than 64K and not an image. The length returned varies depending on the length of the byte array I inserted. If I compress the image so it's around 20K it is returned from the select statement as the same size and is displayed as an image. The database is in the applications Data folder on a Galaxy Nexus, Android version 4.0.1. This is version 12.0.1.3537. Is this is a bug or are long binary columns limited to 64k on Android? Thanks, Jonathan EDIT I've tried both resultset.getBytes(x) and resultset.getBlobInputStream and both have returned the same byte array (the wrong one). EDIT(Calvin) PreparedStatement command_statement; command_statement = connection.prepareStatement(commandText); command_statement.set(x + 1, byteArray); Log.v("Test","Insert Byte Array - " + Integer.toString(byteArray.length)); |
|
After consulting with Chris, I have determined that this is a bug with PreparedStatement.set(int,byte[]). The byte array is limited to 32 KB in size right now. I will fix that in an upcoming release. There is no such limitation on long binary columns in UltraLite databases, and, as a workaround, you could use PreparedStatement.getBlobOutputStream(int) to get a java.io.OutputStream, and use that to write the value into the long binary field. Thanks. Do you have a engineering number to track this bug? I doesn't look like it was fixed in the April 30th release. Thanks
(02 May '12, 16:26)
dmck
The engineering case is 705696 and was addressed in 12.0.1.3721 or later. The EBF released on April 30th is 12.0.1.2718 and as such does not include this change.
(02 May '12, 16:30)
Chris Keating
Replies hidden
FWIW, the CR description is here.
(03 May '12, 03:22)
Volker Barth
|
Please add the details, how you currently try to read the blob data
Post the code you are using.
Further, please post the code that you are using for both write and read of the binary column. There was a bug, fixed in 12.0.1.3540, with PreparedStatement.set() with a String parameter - see CR 693856. However, this may be a different issue. Thanks.
After reviewing the consolidated database it is the insert that is failing. If I take the bytearray that I pass to the set method it's 707784 long. If I look in the consolidated database it's 52424. The code we use for the insert is
PreparedStatement command_statement; command_statement = connection.prepareStatement(commandText); command_statement.set(x + 1, byteArray); Log.v("Test","Insert Byte Array - " + Integer.toString(byteArray.length));
I just updated to 3605 with no change in the result.