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!

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.