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.
thx mr jamal numan
The solution should be similar to the one related to SQL server. The only trick in SQL Server is to choose the correct collation when creating the database (as it appears in the screenshot below).
Jamal NUMAN
Hello mr numan , i have the same problem but i use oracle 11g do u have any idea what is the problem ?
I have the same problem but with oracle 11G ?
Jamal,Could you be a little bit more specific as to why you "... couldn't do this check ..."?? Were you unable to check the "Binary-code point" option in the dialog you made a screenshot of and that I attached below again? If so, this might be due to the fact that you also checked/selected "Case insensitive" and "Accent insensitive" or any of the other available options. If I understand it well, "Binary-code point" collations more or less use a predefined table with the sorting order fully determined (this is the code point/page, see this page and this page about character encoding and code pages on Wikipedia). This means you can't add options like "Case insensitive". Also see the following small remark below from this MSDN page, which confirms this incompatibility. So you will probably need to uncheck all other collation options before checking the "Binary-code point" collation option:"If BIN or Binary-code point is selected, the Case-sensitive, Accent-sensitive, Kana-sensitive, and Width-sensitive options are not available."I guess you are in the right place, but in your case the statement is probably going to look a bit more like:"ALTER TABLE dbo.Communities_24 ALTER COLUMN CommunityName_Points_Arabic COLLATE Arabic_BIN2"In case you wish to try to set a "Binary-code point" (BIN2) collation on this specific column.
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�?�[ATTACH=CONFIG]22117[/ATTACH]
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 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 geodatabase3. I copied the feature class to it4. I tried the sql search! But no luck! It didn�??t work without the �??N�?�BestJamal
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 TerminologyExample from the page:ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AIAnd 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 StylesBut 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.
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.BestJamal
You must use the N prefix before the character string when querying unicode data like thiseg.where name = N'character_string'This article describes the issue and solution in more detail: http://support.esri.com/en/knowledgebase/techarticles/detail/32474
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
