Solved! Go to Solution.
shannon search from attribute table doesn't work either, its standard way to write N before uni code string and we know that but i cant figure out why geodatabase that is stored in sql cant find unicode from attribute table form sql writing select statment works fine.
You must use the N prefix before the character string when querying unicode data like this
where name = N'character_string'
This article describes the issue and solution in more detail: http://support.esri.com/en/knowledgebase/techarticles/detail/32474
Using the �??N�?� is sufficient without the need to install the collation designator. What do you think Marco? However, installing the �??Arabic�?� collation might be still needed referring to the fact that my database includes Arabic fonts. It should be necessary to avoid other types of error and weird behaviour.
Jamal, I still think it would be worthwhile to set the collation to Arabic and try to re-load the data in your geodatabase (re-loading to force setting of Arabic collation on the Arabic unicode column). If I understand it well, your queries should than not need the "N" prefix, which is more consistent with the normal ArcGIS usage and less confusing to you or your geodatabase users.
As the ArcGIS troubleshooting page also states: "No results are returned by ArcMap unless the SQL Server instance being queried is using a (Thai) locale or collation."
Alternatively, you might still try to change the collation of specifically the Arabic character column in SQL Server Managent Studio by using the ALTER statement against the column, as explained on this page (scroll down to see it under "Column-level collations"):
Collation and International Terminology
Example from the page:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI
And as you also say, it should potentially give a more consistent behaviour with the sorting of the data in different applications and SQL Server.
There also seem to be some new things with SQL Server 2008 and collations and a recommendation and push by Microsoft to use "BIN2" binary collations by checking the "Binary-code point" checkbox in the dialog you made a screenshot of. See this Microsoft MSDN page under "Binary collations":
Windows Collation Sorting Styles
But anyway, as I wrote before this is all a bit outside my knowledge base. I think Vince or Shannon might be able to give better informed answers on this specific subject.
Thank you Marco for the input.
That�??s exactly what I did! You should be able to find this on my previous screenshot (enterprise geodatabase with that feature class)
1. I added the �??Arabic�?� as Collation designator (adding feature to an existing instance)
2. Then I created an enterprise geodatabase
3. I copied the feature class to it
4. I tried the sql search! But no luck! It didn�??t work without the �??N�?�
Jamal, did you also try to set a "Binary-code point" collation? This should force Unicode comparison in SQL Server. See this text from the MSDN page:
"Binary-code point (_BIN2)
Sorts and compares data in SQL Server tables based on Unicode code points for Unicode data. For non-Unicode data, Binary-code point will use comparisons identical to binary sorts.
The advantage of using a Binary-code point sort order is that no data resorting is required in applications that compare sorted SQL Server data. As a result, a Binary-code point sort order provides simpler application development and possible performance increases. For more information, see Guidelines for Using BIN and BIN2 Collations."
Thank you for the contribution Marco.
I couldn�??t do this check on the sql server database.
Please, have a look on the screenshot below, am I in the right place to stick (as an example)
�??ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI�?�