SQL Server backend problem

[hima193]

I have an access frontend linked to sql server backend
All worked good until i tried to put where condition in nvarchar field
Query result is always nothing

BS all my inputs are in Arabic but everything else is in English

I dont know where is the problem but i cant solve it
Any help will be appreciated.. thanks

Edit:
This is the sql statement

SELECT FullName FROM tblContacts WHERE FullName Like “محمد*”;

 

[isladogs]

We can't work with nothing.
Please post the query SQL for someone to look at.

 

[hima193]

ok bro i added it

 

[theDBguy]

Hi. Just a thought... try using % instead of * as your wildcard character.

 

[The_Doc_Man]

I would have to guess to understand which characters are involved here. I might try a different approach:

SELECT Fullname FROM tblContacts WHERE Left( Fullname, n ) = "{whatever}" ;

However, I recall hearing that Arabic reads right to left. If so, then you might really need to use the Right function rather than the Left function because I cannot tell whether that is actually a request to find names beginning with whatever that was, or ENDING with whatever it was. In either case, when dealing with a non-English alphabet, wildcarding might become interesting but selection of sub-sets should still work normally.

 

[NauticalGent]

I think the DBGuy’s suggestion will do the trick, especially if you are doing a Pass Through Query. Had the same issue until a Google Search set me on the right path...

 

[hima193]

I tried even finding any letter in the field it always return nothing

 

[hima193]

Hi. Just a thought... try using % instead of * as your wildcard character.

Tried but its not working

I even tried this. Like ؜'%{any arabic letter}%’

 

[hima193]

An important thibg i have to mention that if i tried to import the table to access the query works

 

[AccessBlaster]

I have an access frontend linked to sql server backend
All worked good until i tried to put where condition in nvarchar field
Query result is always nothing

BS all my inputs are in Arabic but everything else is in English

I dont know where is the problem but i cant solve it
Any help will be appreciated.. thanks

Edit:
This is the sql statement

SELECT FullName FROM tblContacts WHERE FullName Like “محمد*”;

Dealing with NULLS and nvarchar fields in the backend might be different, especially if your using microsoft management studio to write the SQL statement. Just a guess.

 

[Solo712]

An important thibg i have to mention that if i tried to import the table to access the query works

Check this, https://stackoverflow.com/questions/3560173/store-arabic-in-sql-database

Best,
Jiri

 

[hima193]

Dealing with NULLS and nvarchar fields in the backend might be different, especially if your using microsoft management studio to write the SQL statement. Just a guess.

I am writing the sql statment in access and it dosnt work
If i tried ssms it works if i pu in N before the text
Like this. Like N’ ’

 

[AccessBlaster]

I am writing the sql statment in access and it dosnt work
If i tried ssms it works if i pu in N before the text
Like this. Like N’ ’

hima193, it looks like Solo712: hinted at this in his link: also here is more information on using the N prefix.

https://softwareengineering.stackexchange.com/questions/155859/why-do-we-need-to-put-n-before-strings-in-microsoft-sql-server

By default SQL server uses the Windows-1252 character codes for varchar. It contains most of characters for latin-based languages (English, German, French, etc.) But it does not contain characters for non-latin based languages (Polish, Russian, etc.). As stated by @Pieter B, nvarchar is used to get around that issue because it is for Unicode which contains those missing characters. This comes at a cost, it takes twice as much space to store nvarchar than varchar.
Putting N in front of your string ensures the characters are converted to Unicode before being placed into a nvarchar column. Most of the time you will be okay leaving the N off, but I wouldn't recommend it. It is a lot better to be safe than sorry.

HTH