`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
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`
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`
`select 0x85, _UTF8 '' || (_WIN1251 '' || (_NONE '' || ascii_char(0x85))) from rdb$database`
and friends at
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" !!!)
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!