Hi Robert,
The derby.ui.codeset property doesn't sound like the best solution to
this problem. Is the load actually failing because of the unprintable
characters or are you simply having difficulty inspecting the results
with ij?
If the load is failing, you might try different codeset arguments to the
SYSCS_UTIL.SYSCS_IMPORT_TABLE system procedure. Another solution would
be to wrap your external file in a table function, a subclass of
org.apache.derby.vti.StringColumnVTI which handles the encoding mismatch.
Hope this helps,
-Rick
On 3/26/13 2:15 AM, rgasch wrote:
I am importing a SQL file which originally was created by mysqldump. The
character encoding of this file is UTF-8. For reference, I am doing this on
a Linux machine (although that should not matter).
After massaging the file to account for the syntactic differences in MySql
and Derby, the SQL is processed without errors. However, I am having trouble
correctly loading non-ASCII characters (such as
À,Á,Â,Ã,Å,à,á,â,ã,å,Ò,Ó,Ô,Õ,Ø,ò,ó,ô,õ,ø,È,É,Ê,Ë,è,é,ê,ë,Ç,ç,Ì,Í,Î,Ï,ì,í,î,ï,Ù,Ú,Û,ù,ú,û,ÿ,Ñ,ñ,ß,ä,Ä,ö,Ö,ü,Ü).
I've managed to solve this by using the derby.ui.codeset=utf8 definition in
a properties file, however I would prefer to have a solution which does not
rely on this.
So, in order to achieve this, what character encoding to I have to save this
SQL file in, in order to be able to import data containing such characters
without having to rely on the derby.ui.codeset setting? I know that the
derby docs say that derby expects the files to be encoded in UNICODE, but
somehow that doesn't seem to be equal to UTF8 so I'm at a loss as to what
exactly it expects.
Greetings/Thanks
Robert
--
View this message in context:
http://apache-database.10148.n7.nabble.com/Executing-SQL-file-character-encoding-tp128380.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
