Bug report: CLOBs: specified encoding (UTF-8) is ignored, system enc. used

Using DbVisualizer 9.0.5, Oracle 10g DB, table with CLOB column, database default character encoding is UTF-8 (AL32UTF8). Steps to reproduce the problem: # Create a file with UTF-8 encoding and with some national characters (e.g. cyrillic chars). For example: Датские кинематографисты (I have attached the example file ru.txt) # With DbVis connect to DB, open table data, double-click the cell (CLOB type), select "Open file", specify encoding UTF-8 (attached image img1.png), browse for file ru.txt # Observe, that even in edit window the encoding is lost (file is opened as Cp1257 or ASCII, cyrillic characters not shown) # Commit the record to database. # select the data with the help of: select DBMS_LOB.substr(COLUMN_NAME, 50) from TABLE_NAME; example is shown in attached image img2.png # Observe ASCII symbols, not unicode symbols. Example of correctly working program: NetBeans v7.3, attached image img3.png shows the result of the same query (DBMS_LOB.substr) when file was uploaded with NetBeans. Core problem: CLOB open file dialog does not care about specified encoding, file is always loaded using system default encoding.

Hello Roger, thanks for the fix, worked great. Sorry for being late with feedback, was on holidays ;-) (In beautiful Sweden, ...by the way) Cheers Roland Edited by: Roland on 09.09.2013 10:10

Hi Roland, This is now also included in the just released DbVisualizer 9.1. I hope you had a great time in Sweden. Were did you go? Best Regards, Hans

Hi Hans, i've been around with a small single engine aircraft and after flying alongside the norwegian coastline i entered sweden from Trondheim and have been to Älvdalen, Aleberg (Fälköping), Fjällbacka and Varberg. These are some rural spots with small natural airstrips. Run out of time to visit Stockholm Bromma airfield. Hope to make it next summer. While setting up new DbVis 9.1, i just realized, that my licence expired in april (great new feature to be prompted for that in the future!). So first i have to get a new one. At least i recognized the 'Encoding' setting in the properties tab. all the best Roland Edited by: Roland on 11.09.2013 10:15

Hello Hans, sorry, just found another follow-up-issue in this matter. I'm running DbVis Pro 9.1 now, the rest of my environment is still the same: Product: DbVisualizer Pro 9.1 Build: #2050 (2013/09/08 11:03) Java VM: Java HotSpot(TM) Client VM Java Version: 1.6.0_26 Java Vendor: Sun Microsystems Inc. OS Name: Linux OS Arch: i386 OS Version: 3.2.0-53-generic-pae The 'Encoding' setting in the connection properties is 'ISO-8859-15' (also tried 'windows-1252') The discribed bug in my step-by-step instruction (29.07.2013 09:31) is now fixed, concering the correct hex value of any inserted character. But after reopening the modified cell in the cell-editor, it will display a question mark '?' with a dark background for any non-ascii character in the 'text' tab (see file '1_nonascii_in_text.png'), while in the 'hex viewer' tab it's still the correct hex value(see file '2_nonascii_in_hex.png') . Well, this wouldn't be much of a big problem. If you edit this cell content now in the 'text' tab of the cell editor (e.g. add another character) and close it, and reopen it in cell editor again (see file '3_nonascii_in_text_after_modify.png'), then the formerly correct hex-value is now converted to '3F'' (see file '4_nonascii_in_hex_after_modify.png'), which is the hex-value of the question-mark. This is a problem, because all affected non-ascii characters will end up as question marks in the database. Still the same workaround prevents this behaviour: -Dfile.encoding=ISO-8859-15 By adding this line to the 'dbvis.vmoptions' file, all non-ascii characters are displayed well, also in cell editors 'text' tab, and editing the cell content no longer leads to converted question marks '3F' in the database. Hope this is reproducible for you and helps you getting rid of this. cheers roland