I've create 2 demo DB's.
Server Collation - Hebrew_CI_AS
DB1 Collation - Hebrew_CI_AS
DB2 Collation - Latin1_General_CS_AS.
In DB2 I have one column with Hebrew_CI_AS Collation. I'm trying to insert Hebrew text into that column. The Datatype is nvarchar(250).
This is the sample script:
INSERT INTO [Table] (HebCol)
VALUES('1בדיקה')
When I run this on DB1, everything works fine.
On DB2, Although the column has Hebrew Collation, I get question marks instead of the Hebrew text.
Why is the result different if the collation is identical?
P.S: I cannot add N before the text. In the real world an app is doing the inserts.
When using literal strings the collation used is that of the database, not the destination column. As the collation of the database you are inserting into is Latin1_General_CS_AS then for the literal string '1בדיקה' most of the characters are outside of the code page of the collation; thus you get ? for those characters as they are unknown.
As such there are only 2 solutions to stop the ? appearing in the column:
Fix your application and define your literal string(s) as an nvarchar not a varchar; you are after all storing an nvarchar so it makes sense to pass a literal nvarchar.
Change the collation of your database to be the same as your other database, Hebrew_CI_AS.
Technically there is a 3rd, which is use a UTF-8 collation if you are on SQL Server 2019, but such collations come with caveats that I don't think are in scope of this question.
Related
I have a strange problem. In my SQL Server database there is table containing an nchar(8) column. I have inserted several rows into it with different Unicode data for nchar(8) column.
Now when I fire a query like this
select *
from table
where nacharColumnName = N'㜲㤵㠱㠷㔳'
It gives me a row which contains 㤱㔱〴㐰' as unicode data for nchar(8) column.
How does SQL Server compare unicode data?
You should configure your column (or entire database) collation, so that equality and like operators work as expected. Simplified Chinese of whatever
I have an ACCESS database in which characters are Arabic but displayed like this "ÇáÓíÏ ÇáÇãíä ÇáÚÇã ááÍßæãÉ" , is there any solution to this problem please? Thanks
This is a collation problem.
ALTER DATABASE (Database name here) COLLATE Arabic_CI_AS ;
All databases have a default collation (which can be set when creating or altering a database. This collation is used for all metadata in the database, as well as the default for all string columns within the database. Users can choose a different collation for any particular column by using the COLLATE clause.
Go here, for further reading.
I have a grails application that is intended to insert arabic characters from interface to sql server database. First I did it with field type varchar but it appears ???????. Then I found that the field type should be nvarchar but with, application simply fails to insert any row by giving the following error,
java.sql.SQLException: Cannot insert the value NULL into column 'id', table 'smsCampaigner.dbo.message'; column does not allow nulls. INSERT fails.
I know that this is constraints error that id cannot be null but this was not the case before changing the field type. Now I want to know whether we can specify fro config.groovy which encoding should be used in database ? any other type of help will be appreciated.
here you go..
when you create the domain class use String type for that column and that's it. you could insert any character it will accept.
for example TestDomain.groovy
class TestDomain {
String column1
}
In mysql you can set up the collation of the database/table/column to use utf8_unicode_ci and if I am not wrong that is valid to save arabic chars. Not sure how to do it with SQL Server but it should be something similar.
Change the collation of the database and tables and columns to Arabic_CI_AS
In Sql Server management studio (SSMS), Execute :
ALTER DATABASE DB06 COLLATE Arabic_CI_AS
where DB06 is the name of the database.
right-click on table, then click design, then select the desired column, in its properties, choose the collation to Arabic_CI_AS
by the way, the error :
Cannot insert the value NULL into column
is not related to Arabic, this is because you are trying to insert NULL in the column that does not allow NULL.
I have DB1 which has a Hebrew collation
I also have DB2 which has latin general collation.
I was asked to merge a table (write a query) between DB1.dbo.tbl1 and DB2.dbo.tbl2
I could write in the wuqery
insert into ...SELECT Col1 COLLATE Latin1_General_CI_AS...
But I'm sick of doing it.
I want to make both dbs/tables to the same collation so I don't have to write every time COLLATE...
The question is -
Should I convert latin->hebrew or Hebrew->latin ?
we need to store everything from everything. ( and all our text column are nvarachr(x))
And if so , How do I do it.
If you are using Unicode data types in resulted database - nvarchar(x), then you are to omit COLLATE in INSERT. SQL Server will convert data from your source collation to Unicode automatically. So you should not convert anything if you are inserting to nvarchar column.
I am using SQL Server 2008 express edition and its collation settings are set to default.I wish to store special characeters like á ,â ,ã ,å ,ā ,ă ,ą ,ǻ in my database but it converts them into normal characters like 'a'. How can I stop SQL Server from doing so?
Make sure that your columns are using the type nvarchar(...), rather than varchar(...). The former is Unicode, the latter is ASCII.
Also, make sure that your database default collation is set to Accent Sensitive, and that your columns are stored that way. You may also want to check your instance default collation, as that affects the default collation for your system databases, particularly tempdb.
Rahul, here is a very simple query that runs perfectly on SQL 2005 and 2008:
Query
DECLARE #t1 TABLE (
Col1 nvarchar(30)
)
INSERT INTO #t1 VALUES (N'á ,â ,ã ,å ,ā ,ă ,ą ,ǻ')
SELECT * FROM #t1
Result
Col1
------------------------------
á ,â ,ã ,å ,ā ,ă ,ą ,ǻ
There is nothing special here. No collation change from default, just a simple NVARCHAR column.
You said you are "just running direct queries in the database". Can you try this query and see if you get the same results?