On 17-05-2022 14:47, Adriano dos Santos Fernandes wrote:
On 17/05/2022 08:30, Mark Rotteveel wrote:
Is this happening with fbclient library too?
Good question: no it doesn't. Which suggests Jaybird is doing something
different. Jaybird uses blr_varying/blr_text, not blr_varying2/blr_text2
when sending the BLR of the execute. Could that make a difference?
Changing Jaybird to write blr_varying2/blr_text2 with the sub type
(character set) fixes the issue.
However, I thought that using blr_varying/blr_text (judging by
MetadataFromBlr::MetadataFromBlr in
common\classes\InternalMessageBuffer.cpp, Firebird selects CS_dynamic,
which should use the connection character set (UTF8) in this case. Is it
possible that `CharSet* const fromCharSet = INTL_charset_lookup(tdbb,
from_cs);` doesn't handle CS_dynamic properly? Or that this happens in a
codepath where BLR decoding doesn't assign CS_dynamic, but it remains
zero (NONE)?
The engine is receiving the string using NONE charset, which makes
things bad there.
This happens due to this place:
-----
// ASF: Older than 2.5 engine hasn't validating strings in DSQL. After
this has been
// implemented in 2.5, selecting a NONE column with UTF-8 attachment
charset started
// failing. The real problem is that the client encodes
SQL_TEXT/SQL_VARYING using
// blr_text/blr_varying (i.e. with the connection charset). I'm reseting
the charset
// here at the server as a way to make older (and not yet changed)
client work
// correctly.
if (desc.isText() && desc.getTextType() == ttype_dynamic)
desc.setTextType(ttype_none);
-----
So it is happening for a long time and may make things incorrect in Jaybird.
Anyway, it seems I'll need to change the fix for #7179 to take care of
real NONE/BINARY source strings.
Thanks! I will change Jaybird to switch to using blr_varying2/blr_text2
for Jaybird 4.0.7 and Jaybird 5.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
