When I update my database with this command:
UPDATE myTable SET Name = 'Hermann Dönnhoff' WHERE ID = 123;
SQL Server actually puts 'Hermann Do¨nnhoff' in the field instead. Instead of faithfully inserting the o-umlaut (char(246)), I'm getting two characters ( char(111) + char (168) ).
This happens for all characters that have accent marks, not just umlauts.
Has anybody seen this?
Thank you.
You need to use the nchar, nvarchar, or ntext datatypes for Unicode data.
The issue is that your code page does not directly support those characters.
Read up on collations for more information:
http://msdn.microsoft.com/en-us/library/aa214408%28SQL.80%29.aspx
http://msdn.microsoft.com/en-us/library/aa174903%28SQL.80%29.aspx
Related
Our ETL team is sending us some data with chinese description. When we are loading that data in our SQL Server database, those descriptions are coming up as blank.
We tried changing the column format to nvarchar, but that doesnt help.
Can you please help.
Thanks
You must use the N prefix when dealing with NVARCHAR.
INSERT INTO table (column) VALUES (N'chinese characters')
Prefix a Unicode character string constants with the letter N to
signal UCS-2 or UTF-16 input, depending on whether an SC collation is
used or not. Without the N prefix, the string is converted to the
default code page of the database that may not recognize certain
characters. Starting with SQL Server 2019 preview, when a UTF-8
enabled collation is used, the default code page is capable of storing
UNICODE UTF-8 character set.
Source: https://learn.microsoft.com/en-us/sql/t-sql/data-types/nchar-and-nvarchar-transact-sql?view=sql-server-2017
I have to store some strange characters in my SQL Server DB which are used by an Epson Receipt Printer code page.
Using an INSERT statement, all are stored correctly except one - [SCI] (nchar(154)). I realise that this is a control character that isn't representable in a string, but the character is replaced by a '?' in the stored DB string, suggesting that it is being parsed (unsuccessfully) somewhere.
The collation of the database is LATIN1_GENERAL_CI_AS so it should be able to cope with it.
So, for example, if I run this INSERT:
INSERT INTO Table(col1) VALUES ('abc[SCI]123')
Where [SCI] is the character, a resulting SELECT query will return 'abc?123'.
However, if I use NCHAR(154), by directly inserting or by using a REPLACE command such as:
UPDATE Table SET col1 = REPLACE(col1, '?', NCHAR(154))
The character is stored correctly.
My question is, why? And how can I store it directly from an INSERT statement? The latter is preferable as I am writing from an existing application that produces the INSERT statement that I don't really want to have to change.
Thank you in advance for any information that may be useful.
When you write a literal string in SQL is is created as a VARCHAR unless you prefix is with N. This means if you include any Unicode characters, they will be removed. Instead write your INSERT statement like this:
INSERT INTO Table(col1) VALUES (N'abc[SCI]123')
I need your help on this: I am using SQL Server 2008 and have a stored procedure which is used to retrieve values from a table column.
Column of table contains description which could have anything including all special characters.
Is there any way I can escape all special characters ?
Thanks
try this
WHERE Description LIKE '%\ any text%'
here \ means ESCAPE
The problem is that DBI's insert leaves long string truncated when inserting to MS SQL server. Here are my codes:
my $insert = $dbh->prepare("INSERT INTO my_table (field_1, field_2) values (?, ?)");
$insert->execute($value_1, $value_2);
where field_2 has data type of varchar(100) and $value_2 is a text string of 90 characters with spaces but no other special characters.
After the statement is executed, with no error raised, I checked the database and apparently the actual inserted $value_2 is truncated at the 80th character, which is in the middle of a regular English word (i.e. not a special character).
I've tried to alter the data type of field_2 to varchar(150) and text. I've also used $dbh->quote($value_2) in place of $value_2. But they didn't help.
Why is this happening? What should I do? Thx!!
If you are using freeTDS it is probably a bug identified in the freeTDS mailing list. See freetds silently truncating text/varchar/etc fields to 80 characters and http://lists.ibiblio.org/pipermail/freetds/2011q2/026943.html and http://lists.ibiblio.org/pipermail/freetds/2011q2/026925.html and http://lists.ibiblio.org/pipermail/freetds/2011q2/026944.html
I'd say try various strings to see if they all behave the same way. It's probably an encoding issue as davorg suggests. The default collation in MySQL is Swedish or Latin1 as I recall, so in MySQL you'll probably want to change your collation to utf8_general_ci.
How can I insert Arabic characters into a SQL Server database? I tried to insert Arabic data into a table and the Arabic characters in the insert script were inserted as '??????' in the table.
I tried to directly paste the data into the table through SQL Server Management Studio and the Arabic characters was successfully and accurately inserted.
I looked around for resolutions for this problems and some threads suggested changing the datatype to nvarchar instead of varchar. I tried this as well but without any luck.
How can we insert Arabic characters into SQL Server database?
For the field to be able to store unicode characters, you have to use the type nvarchar (or other similar like ntext, nchar).
To insert the unicode characters in the database you have to send the text as unicode by using a parameter type like nvarchar / SqlDbType.NVarChar.
(For completeness: if you are creating SQL dynamically (against common advice), you put an N before a string literal to make it unicode. For example: insert into table (name) values (N'Pavan').)
Guess the solation is first turn on the field to ntext then write N with the value. For example
insert into eng(Name) values(N'حسن')
If you are trying to load data directly into the database like me, I found a great way to do so by creating a table using Excel and then export as CSV. Then I used the database browser SQLite to import the data correctly into the SQL database. You can then adjust the table properties if needed. Hope this would help.