Subject | Re: [firebird-support] Debugging BLOB problems |
---|---|
Author | Helen Borrie |
Post date | 2005-08-25T23:26:56Z |
At 07:52 PM 25/08/2005 +0200, you wrote:
db interface component issue. As far as Firebird is concerned: you should
pass a blob to a blob column; with a certain "relaxation" for text
(sub_type 1) blobs. For these, you can pass a string constant of 32,767
bytes or less and the parser will silently convert the string to a text
blob without raising an exception. If you try to pass a string of more
bytes, Firebird would throw string overflow/conversion exceptions.
For replaceable parameters, you would get an exception unconditionally if
you tried to apply a string to a blob parameter.
So ----------------
The fact that you are writing and retrieving your blobs without Firebird
exceptions suggests one of the following (by no means an all-inclusive
list!!):
1. your interface component is treating the content of a text blob as a
multi-byte character set. Your numbers are not quite consistent with this
idea, since (for example, a Kylix widestring, 2-bytes per character) 32767
/ 2 is slightly less than 16510. Still, if the interface was handling,
e.g., blanks and unaccented characters as single bytes, this explanation
might still be consistent with what you see.
2. related to 1), the character set setting for the client (lc_ctype) is
set to NONE, ASCII, or some other single-byte character set, while the
database or the column is defined as some multi-byte set. A certain amount
of tolerance to this condition was added to Fb 1.5.2...but you don't say
what version of Firebird (client and server) are in use.
3. You are using a driver that supports an absolute size limit on strings
(if strings are involved) or on blobs/clobs.
4. Or it may be the case that the blobs are being stored correctly, but
the size of the client buffer that is being used to accommodate query
output is limited.
You don't mention the driver you are using. However, if it is one that has
a support list, it would be your most likely source of leads.
./heLen
>Hi,You don't say what components you are using but this is most likely to be a
>
>I'm currently experiencing some weird behaviour with BLOB fields, and I'm
>having problems tracking down the cause of these problems. All I can see is
>that the content looks ok "the last time I see it", then it passes through the
>chain Qt --> libgds --> firebird, and when I fetch the data from the database,
>the BLOB is reduced to 16510 bytes. I do not have the slightest idea which of
>the components is responsible for this problem, so my question is - is there
>any way to trace or debug the execution of my insert statement?
db interface component issue. As far as Firebird is concerned: you should
pass a blob to a blob column; with a certain "relaxation" for text
(sub_type 1) blobs. For these, you can pass a string constant of 32,767
bytes or less and the parser will silently convert the string to a text
blob without raising an exception. If you try to pass a string of more
bytes, Firebird would throw string overflow/conversion exceptions.
For replaceable parameters, you would get an exception unconditionally if
you tried to apply a string to a blob parameter.
So ----------------
The fact that you are writing and retrieving your blobs without Firebird
exceptions suggests one of the following (by no means an all-inclusive
list!!):
1. your interface component is treating the content of a text blob as a
multi-byte character set. Your numbers are not quite consistent with this
idea, since (for example, a Kylix widestring, 2-bytes per character) 32767
/ 2 is slightly less than 16510. Still, if the interface was handling,
e.g., blanks and unaccented characters as single bytes, this explanation
might still be consistent with what you see.
2. related to 1), the character set setting for the client (lc_ctype) is
set to NONE, ASCII, or some other single-byte character set, while the
database or the column is defined as some multi-byte set. A certain amount
of tolerance to this condition was added to Fb 1.5.2...but you don't say
what version of Firebird (client and server) are in use.
3. You are using a driver that supports an absolute size limit on strings
(if strings are involved) or on blobs/clobs.
4. Or it may be the case that the blobs are being stored correctly, but
the size of the client buffer that is being used to accommodate query
output is limited.
You don't mention the driver you are using. However, if it is one that has
a support list, it would be your most likely source of leads.
./heLen