|
I'm using v16.0.0.2158 with a German locale. While trying to migrate a v12.0.1 database to v16.0.0.2158, 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. Hm, that sounds really irritating for a German-based database and application - I certainly do not use the Cyrillic alphabet but instead make frequent use of German umlauts (therefore the choice of Windows-1252) and the like in comments or messages with SQL code. And when opened with the desired encoding the database objects are created as expected... If I'll find the time, I'll check the characters in that script. Might the values of LOAD STATISTICS statements be of influence here?
(12 Aug '15, 01:19)
Volker Barth
Neither of the LOAD STATISTICS nor the LOAD TABLE statements should play a role. My suspicion it would have more to do with the comments and create object statements.
(17 Aug '15, 12:47)
Nick Elson S...
The initial choice of encoding is done by DBISQL (rather than the database server), and is based on the characters in the file you are opening (e.g. RELOAD.SQL). Database statistics do not enter into it, as Nick says.
(17 Aug '15, 15:43)
ChrisIrie
Replies hidden
To clarify: I was not relating to database statistics but to the binary strings that make up the statistics values in the LOAD STATISTICS statements, such as LOAD STATISTICS "dbo"."MyTable"."MyPk"
64, 5.30740453542E-6, 20, 20, 0x000000000000f03f000000000000f03f0000000000afc4400000000080a1d440000000000017e140000000000049e140000000006037ea40000000002033f040000000002042f340000000002034f64000000000b001f94000000000a0bdfb4000000000f0a5fe4000000000b0cb00410000000098300241000000008880034100000000d8d4044100000000f81906410000000068e407410000000058901441,
0x00000000c4ac5c361567043d2e6b033d0ad4fa3cf7e6a43a9d2f133dbc2f1d3d8b6e183d22b9113d16e70b3dc7ed043db1fbec3c2da4e13c50f3e63c94a5f03c2fe8e53c4e48ea3c6d6f353df834e43e
(18 Aug '15, 01:53)
Volker Barth
Comment Text Removed
Comment Text Removed
|
FWIW, the ISQL option "default_isql_encoding" is not set.
Wow... I have never seen that dialog box! Have I been living under a rock in Windows-1252-Land? :)
Don't know - I mostly live in the ancient dbislqc caves:)
FWIW, this happens with 12.0.1.4278, too.