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

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


2

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


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


1

I had this error, and now I have discovered the source of the problem. I had a hard time finding out, so maybe this will be useful to someone, even though I realize, my problem and workaround may not be spot on matching op's original trouble. I am migrating data from MSSQL to MySQL, and the content being migrated is html-content from Sitecore CMS (target ...


1

At MySQLBugs they suggested trying with binaries available at MySQL Community Downloads . Downloaded: mysql-5.5.8-freebsd8.0-x86_64.tar.gz Extracted to: /usr/local/mysql-5.5.8-freebsd8.0-x86_64 Linked to /usr/local/mysql And re-compiled/re-installed p5-DBD-mysql against it by doing the following: export PATH=/usr/local/mysql:$PATH cd ...


1

The chinese characters are decoded correctly with utl_i18n.unescape_reference. In fact they just aren't displayed properly in your query result which might not support those special characters. You can confirm that with this SQL Fiddle. It is the client which is respsonsible to display the characters appropriately. If the client can not display a ...


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



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