I'm using v220.127.116.118 with a German locale.
While trying to migrate a v12.0.1 database to v18.104.22.1688, I have used v16's dbunload to create a reload.sql file which has been created with default encoding. (I.e. I have not specified any particular encoding in DBUNLOAD's connection string.)
The unmodified reload.sql file contains that initial comments:
After starting DBISQL and connecting to the created v16 database, I open the according reload.sql file, and I'm asked the following:
When accepting the suggested Windows-1251 encoding (say, because it was early in the morning), the database is apparently created with mangled SQL code as the code actually is in Windows-1252, as common in German locale. So any umlauts and the like are lost. (The table data however is loaded correctly, as the LOAD TABLE statements bear the correct "ENCODING 'windows-1252'" clause).
Question: Why does DBISQL make such a poor choice here? (V17 behaves the same, FWIW.)
(I have not tested what encoding is used as "(Standard)", instead I have pressed the "Show more encodings" button and chosen to use "Windows-1252" explicitly.)
FWIW: Changing the locale to EN does not influence that behaviour, DBISQL still suggests Windows-1251...
When you open a file in DBISQL, it attempts to guess the codepage it should use to read the file. It does this (in part) by doing a statistical analysis of the characters in the file. Apparently, there is a mix of characters in your RELOAD.SQL file which suggests that it was saved with Windows-1251 rather than Windows-1252.
Selecting the "(Default)" encoding tells DBISQL to use your computer's current file encoding. If you're on a Windows machine, that's the ANSI encoding, as opposed to the OEM encoding.
answered 11 Aug '15, 12:43