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

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 ...


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

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

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

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 ...


2

https://dev.mysql.com/doc/refman/5.7/en/replication-features-differing-tables.html describes the supported variations in table definitions. For one, it appears that this is supported with statement-based replication: When using statement-based replication, a simple rule of thumb to follow is, “If the statement run on the master would also execute ...


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

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

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

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 = ...


1

MySQL and MariaDB handle character sets the same. However... Different versions of MySQL have different defaults. Ditto for MariaDB. SET NAMES declares what encoding is in the client. This is independent of the CHARACTER SET on a column or table. (There are, of course, characters that are not representable in latin1, so there can be conversion problems....


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

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

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 ...



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