Arioch
`select ascii_char(0x85) from rdb$database`
There is no possible way to save the session to the command above, but you may change two digits at the following session and see
https://dbfiddle.uk/?rdbms=firebird_3.0&fiddle=19c800380f4c6f29513ddea28f12ac3a
This query fails, i suspect it fails around charsets conversion (this char is of Windows-1251 codepage and probably violates UTF-8 format, which maybe is used between DBFiddle and FB).
Just shooting to the stars, because - and that is the issue - DB Fiddle reports no any details about error this time.
Yet stranger, if i lock the charset - it still generates the same info-less error.
`select 0x85, cast(ascii_char(0x85) as VarChar(4) character set win1251) from rdb$database`
https://dbfiddle.uk/?rdbms=firebird_3.0&fiddle=5590f43300d8c8474eeb5d61f2435377
This latter thing seems to go beyond "error information loss" into "failure to transcode", but i am not sure, as there is no error information :-)
I even try double-envelope and it still fails.
`select 0x85, cast(cast(ascii_char(0x45) as VarChar(4) character set win1251) as VarChar(4) character set UTF8) from rdb$database`
Hmmm, now this is getting truly weird. So i run `select RDB$CHARACTER_SET_NAME from rdb$database` and bingo! i get the dangerous binary-only `NONE` as result. Sometimes backward-compatibility hurts...
I think the database connection properties were not set up completely. Try to read your language of choice docs and also about (if i remember correctly, but i am not sure) `lc_ctype` connection string parameter. But it may be different with your language/library.
Now, triple-enveloping to the rescue - and it finally trips no more :-)
`select 0x85, cast(cast(cast(ascii_char(0x85) as VarChar(4) character set OCTETS) as VarChar(4) character set win1251) as VarChar(4) character set UTF8) from rdb$database`
and
`select 0x85, _UTF8 '' || (_WIN1251 '' || (_NONE '' || ascii_char(0x85))) from rdb$database`
and friends at
https://dbfiddle.uk/?rdbms=firebird_3.0&fiddle=6e28fb5b97cc490da8fc135e05ac54e6
Resume: three problems with DBFiddle/Firebird
1. Failure to report errors happening after FB passed results out.
2. Failure to save SQL session and generate unique URL when such an error happens.
3. Failure to declare human-targeted connection charset, perhaps UTF8 would be good default choice (but NOT "UNICODE" !!!)
Top Answer
Jack Douglas
We have:
1. Set the default charset to UTF8 for the database
2. Done the same for the connection
3. Added error trapping for returned data that is incompatible with UTF8
This seems to have cleared up all the issues!