Tag Info

Hot answers tagged

3

You have to specify that you are inserting wide character data: CREATE TABLE #t (id INT,c1 VARCHAR(MAX),c2 NVARCHAR(MAX)); INSERT INTO #t VALUES(1,'žđšćč žđćčžđšćčŽĐŠĆČ','žđšćč žđćčžđšćčŽĐŠĆČ'); INSERT INTO #t VALUES(2,N'žđšćč žđćčžđšćčŽĐŠĆČ',N'žđšćč žđćčžđšćčŽĐŠĆČ'); SELECT * FROM #t; DROP TABLE #t; Result:


2

MySQL's documentation for utf8 shows that it will use 1 byte for Latin characters, and only use more if the situation requires them. Therefore, if you're only using normal latin characters, both utf8_general_ci and latin1_general_ci will use between 1 and 4 bytes: one byte to store the length (0-3 characters), and then up to three bytes for the actual text. ...


2

I don't think collation is your problem as that is related to sorting and ordering (although you might get a problem later using ORDER BY and so on), but you mention you have some VARCHAR fields. Those will not accept Unicode characters (which Cyrillic certainly are): They will need to be NVARCHAR throughout to do that. Next, how are you inserting your ...


1

since you confirmed the character set in the database is AL32UTF8, you need to make sure the fonts is installed on the Linux machine, and install the message libraries. that will make ORA_NLS33 has been set appear when you execute alter session set nls_language=


1

You may have fragmentation in the table meaning that you could reclaim space by running the optimize command on the table. Check the free_data column from show table status like 'table_name'. Further reading; http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html If you are using the innodb storage engine (and you generally should with narrow ...


1

If it is the "world" database downloaded from here, it is in latin1 encoding. Use that for importing. UTF-8 (utf8 or utf8mb4 in MySQL) has become the de facto standard nowadays for operating systems and global comunications (except in some countries and specific areas of knowledge), and utf8 is now the default encoding in MySQL (since 5.5). latin1 was the 1 ...


1

Ok, this basically means: The National character set of the database you exported from was AL16UTF16. This is a multi-byte character set and, being the national character set, would have been used for any NCHAR, NVARCHAR and NCLOB columns (the N in the name stands for "national"). The "normal" character set of the database you exported from was ...


1

psql detects the client_encoding from the LC_CTYPE variable in the environment; this falls back to LC_ALL and then LANG if unset. In the terminal you're launching psql from, run locale. e.g. $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" ...



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