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.
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
