Re: [firebird-python] reading blob from table

[Hamish Moffatt]

I found that it works with kinterbasdb for UTF8 or NONE connection type.
I tried changing the column definition to "blob binary character set 
none" and some other things but none of them helped with fdb (1.0). For 
some combinations of the column type and the connection character set I 
got Python utf8 decode errors, others just truncated the data. Also 
tried with a Firebird 2.5 server (I was using 2.1) without any success.

Hamish

On 8/04/2013 2:16 PM, Hamish Moffatt wrote:

Hi,

Thanks Pavel. I tried with charset NONE set when opening the 
connection but the behaviour did not change.


regards
Hamish

On 8/04/2013 2:08 AM, Pavel Cisar wrote:

Hi,

I think it's problem with implicit conversion. Could you please try to
fetch this blob with connection character set NONE?

regards
Pavel Cisar
IBPhoenix

Dne 6.4.2013 15:18, Hamish Moffatt napsal(a):
> Hi,
>
> I am using fdb 0.9.9 and Firebird 2.1 and I trying to fetch some data
> out of tables containing blobs. However the blobs I get back are always
> truncated at the first null.
>
>
> One such table is defined as
>
> SQL> show table g_mididrum;
> DRUM_NUMBER INTEGER Not Null
> DRUM_NAME (DOM_MIDI_NAME) VARCHAR(30) Nullable
> DRUM_WAVE BLOB segment 80, subtype BINARY
> CHARACTER SET NONE Nullable
> DRUM_WAVE_6 BLOB segment 80, subtype BINARY
> CHARACTER SET NONE Nullable
> DRUM_WAVE_12 BLOB segment 80, subtype BINARY
> CHARACTER SET NONE Nullable
> CONSTRAINT PK_G_MIDIDRUM:
> Primary key (DRUM_NUMBER)
>
> I'm making the query "SELECT * FROM G_MIDIDRUM". The cursor's
> description field after the query says
>
> (('DRUM_NUMBER', <type 'int'>, 11, 4, 0, 0, False), ('DRUM_NAME', <type
> 'str'>, 120, 120, 0, 0, True), ('DRUM_WAVE', <type 'str'>, 0, 8, 0, 0,
> True), ('DRUM_WAVE_6', <type 'str'>, 0, 8, 0, 0, True), 
('DRUM_WAVE_12',
> <type 'str'>, 0, 8, 0, 0, True))
>
> The data in DRUM_WAVE (for example) is coming back as a string with
> len() of only 6 or 7 octets. However if I ask firebird to select the
> OCTET_LENGTH(DRUM_WAVE), it tells me the real length which are all 7000
> bytes up to >128k.
>
> I tried using stream blob mode on this column, I get a BlobReader, and
> when I read() all the data from it I still only get 6 or 7 octets.
>
> The connection charset is "UTF8".
>
> I got the same effect in kinterbasdb. We access this table from a 
C++/Qt
> app with the same query ok though. Can you point out my mistake?