Closed AlexDeeep closed 2 years ago
Interesting. It's certainly a flaw in driver, as it should be able to handle non-ascii error messages. I'll add optional encoding parameter to iUtil_v2.format_status(). However, this function is called from iVersioned "internal" __report() that's called from _check() function, that is used to verify result of the call from all interfaces where applicable. So, I'm going to add the encoding property to iVersioned (with default None), and also to Connection class (with default as connection charset). The tricky part will be the "distribution" of encoding to interfaces (descending from iVersioned) used internally by Connection (and other end user classes). As it's pointless to set it on ALL classes and interfaces, I have to assess each one, which will take time. But you can count that it will appear in next driver release.
Well, I decided to handle it differently. The firebird.driver.fbapi defined sys_encoding with value locale.getpreferredencoding() that was used in exception_from_status to decode the error message. I used this method also for iUtil.format_status, and for convenience renamed the variable to "err_encoding". Both decode calls now also define errors="replace" to prevent exceptions there. So, if locale.getpreferredencoding() would not return the proper value (for example because the remote server uses different encoding that client), you may change the value of firebird.driver.fbapi.err_encoding.
Hello, Pavel
I have an error if procedure execution returns exeption with non ascii-127 symbols and i call rollback for transaction:
My fdb encoding is cp1251, but for connection i forced to use UTF-8 charset, otherwise it crashes in other cases
myconnect = fdb.connect(database=dbpath, user=uname, password=upass, charset='UTF8')
My fast local solution is modifying function format_status, :
Would you create a global variable for connection to specify database encoding for cases like this