Hot answers tagged

7

First, as you have now seen, you cannot directly alter meta-data in the system views. However, you could change the setting for a particular database using ALTER DATABASE: ALTER DATABASE { database_name | CURRENT } COLLATE collation_name; Please note that the option to use the CURRENT keyword was introduced in SQL Server 2012. OR, if you only want to ...


2

Choosing character set usually based on the environment, each set has pros and cons. for example if your system has mixed character I strongly recommend utf8 but even utf8 has many types. for example: utf8_general_ci is faster than utf8_unicode_ci but less accurate for sorting. and if you want to use specific language Czech for example then you need to make ...


2

Depending on what RDBMS you are using: You can try altering the Latin1-encoded column to use an encoding of UTF-8, if the RDBMS supports such an operation. If you are using MySQL, you should look at this related Question on S.O.: Converting mysql tables from latin1 to utf8 You can try: Adding a new column with an encoding of UTF-8 UPDATE new_column = ...


2

CHAR(...) CHARACTER SET utf8 always takes 3 bytes per character -- CHAR(100) occupies 300 bytes (no length needed). VARCHAR occupies 1-2 bytes for a length, plus only as many bytes as needed. So VARCHAR(100) with hello will occupy 7 (2+5) bytes in any character set. Señor, in CHARACTER SET latin1, take 5 bytes (plus length). In utf8, it takes 6 bytes ...


2

You can't install UTF-8 as a character set because it's not a character set, it is an encoding. If you want to store Unicode text you use the nvarchar data type. If you want to store text encoded using UTF-8, you store it as binary data (varbinary).


2

According to the documentation: Oracle strongly recommends that you do NOT set the NLS_LENGTH_SEMANTICS parameter to CHAR in the instance or server parameter file. This may cause many existing installation scripts to unexpectedly create columns with character length semantics, resulting in runtime errors, including buffer overflows.


2

There's a useful page here that details any pros/cons/issues that you may encounter when setting the NLS_LENGTH_SEMANTICS parameter. To answer your question, make sure you set NLS_LENGTH_SEMANTICS=BYTE when running any Oracle "internal" scripts. IE: patches, upgrades, anything in $ORACLE_HOME/dbms/admin.


2

Case or accent sensitivity behavior is defined by the collation you are using. The full list of comparable characters in a given collation can be found in collationcharts where you find the MySQL list of collations If you find your collation in that list you will see a chart of comparable characters.


2

Here is a summary of the utf8 collations: http://mysql.rjweb.org/utf8_collations.html It shows that 'n' and 'ñ' are considered equal for all but utf8_bin, utf8_spanish2_ci, and utf8_spanish_ci In the Spanish cases, Ñ and ñ are treated like a separate letter and sort after nz and before o. (Latvian and Polish have a couple of flavors of n that work like ...


1

The NLS_LANG parameter is used by the Oracle network layer to do character translation between the client and the database. This way the client can display all the characters in the database in a 'correct' way. Your NLS_LANG should match the character-set of your database when you do an export. If you export a UTF-8 database in US7ASCII then you risk to ...


1

First of all, character set UTF-8 does not exist on Oracle, use AL32UTF8 or UTF8 (without the hyphen). Usually you should get an error when your client character set is UTF-8: $ setenv NLS_LANG AMERICAN_AMERICA.UTF-8 $ sqlplus ... ERROR: ORA-12705: Cannot access NLS data files or invalid environment specified Character set UTF8 is identical to AL32UTF8 ...


1

HSQLDB stores text data as Unicode. You can verify that by opening the .script file for the database and looking at the data. For example, for a table with a row containing "Montréal" the .script file contains CREATE MEMORY TABLE PUBLIC.TABLE1(ID INTEGER PRIMARY KEY,TEXTCOL VARCHAR(50)) ... INSERT INTO TABLE1 VALUES(1,'Montr\u00e9al') where \u0039 is the ...


1

Interesting question. It looks like in second scenario you firstly convert default charset for table: To change only the default character set for a table, use this statement: ALTER TABLE tbl_name DEFAULT CHARACTER SET charset_name; So then you try to MODIFY charset of your xml column. But database may think that this column is already in the ...


1

This is a rather general question so my answer will be also quite general... Consolidate everything to UTF-8! If possible reload at least the latin1 entries: This time converting latin1 to UTF-8 which should always be possible. Depending on the database product the conversion can be performed by the import tool. Starting with flat files and a custom ...


1

You can edit the dump file and change the included NLS_LENGTH_SEMANTICS from BYTE to CHAR. Near the beginning of the file you find a line ending like this : ^@02:00:^@^@^D^@BYTE^F^@UNUSED^A^@2^K^INTERPRETED^K^@DISABLE:ALL^@^@ Change BYTE to CHAR using your favorite text editor and save the file. When you will imp that new dump file, all columns will be ...



Only top voted, non community-wiki answers of a minimum length are eligible