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

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


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

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

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


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

I had the same problem with an Ubuntu installation of MySQL 5.6.23. I had to edit /etc/mysql/my.conf and add these entries to these sections: [client] default-character-set=utf8mb4 [mysqld] character-set-server = utf8mb4 [mysql] default-character-set=utf8mb4 Then as root execute: service mysql restart Both my webserver connections and my local ...


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


1

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


1

Thanks for the minimal test case. Your TEXT column is declared to be latin1; there is no "dotless i", in latin1, so it was converted from utf8's hex C4B1 to ? during INSERT. Change the table declaration, preferably to utf8. Also remove SET CHARACTER SET utf8; -- It seems to hurt! If you wish to complain about the "silent" conversion, file a bug with ...


1

I made some attempts to dig into this issue, here are the results. When you set a connection charset (i.e. SET NAMES utf8) MySQL transparently handle encoding conversion for you. For instance if I insert a à (\xE0 in latin1 \xC3A0 in utf8) in a latin1 table using a UTF8 connection it reads the UTF 8 value and store it in table as \xE0 mysql> SELECT ...


1

I assume you will do this for each table? ALTER TABLE tbl CONVERT TO CHARACTER SET utf8mb4; One potential issue involves the maximum of 767 bytes per column in an INDEX. If you currently have a VARHAR(255) latin1 field in an index, you will need to rethink it. Decrease it to VARCHAR(191) if you are sure that 191 will suffice (into the future) Use a ...


1

MySQL has no way to split a cell into a bunch of values. (Yeah, it can split a piece of a cell off -- see LEFT(), etc. But not an arbitrary set.) You would be better off doing the task in PHP or some other language -- more powerful than SQL. (Yeah, it could be done in a Stored Procedure, the the code would be really messy.) Here is some pseudo code for ...



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