none
Searching Japanese text does not work RRS feed

  • Question

  • I have asked this question in the SQL Server forum. During the course of discuss one of the user pointed me to this forum and I felt that this is more relevant to EF. http://social.msdn.microsoft.com/Forums/en/transactsql/thread/795ff2fb-df45-4288-acbf-478c15378842

    I have a user table that stores names in English and Japanese. The web application layers use the following technologies

    ASP.Net <----> EF 4 <----> SQL Server 2008

    EF4 does not to return any data when searching for Japanese names. Stored procedures are being employed for data retrieval operations. All the stored procedure parameters are of nvarchar type and the data is stored in the tables as nvarchar type as well.

    Stored procedures work fine in SSMS. exec sp_search_user N'Japanese text', N'Japanese Text'

    Here is what I got from SQL Profiler: exec sp_search_user '??', '??'

    The Japanese text got replaced with ??

    Adding the following @ Page directive had no impact on the outcome:

    <%@ Page RequestEncoding="utf-8" ResponseEncoding="utf-8" %>
    

    Suggestions welcome.

    Friday, June 8, 2012 5:53 PM

All replies

  • Basically it looks like someone messed up the encoding of text or converted it to an encoding that doesn't support the Japanese characters (such as ASCII).

    Work backwards from the stored procedure.  Did the argument get passed into the stored procedure call correctly?  Show us your stored procedure call.

    Did the data reach the code that calls the stored procedure in tact?  Show us that code too.


    Friday, June 8, 2012 7:43 PM
  • The data reached the data access layer intact and here is the code that makes a call to the function import:

    public IQueryable<UserList> SearchUsers(string first_name, string last_name)
    {
    	//db is the database context
    	ObjectResult<UserList> SearchResult = db.SearchUsers(first_name, last_name);
    	IQueryable<UserList> users = from tmp in SearchResult.AsQueryable() select tmp;
    	return users;
    }
    I have also verified that the East Asian Language pack was indeed installed on the application server.
    Friday, June 8, 2012 7:56 PM
  • Do you get first_name and last_name parameters OK here in that call?

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 8, 2012 8:57 PM
  • Yes the data was intact.
    Friday, June 8, 2012 8:59 PM
  • Is there a possibility to look inside the generated SearchUsers method ?

    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 8, 2012 9:34 PM
  • public virtual ObjectResult<UserList> SearchUsers(string first_name, string last_name)
    {
    	((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace.LoadFromAssembly(typeof(UserList).Assembly);
    
    	var first_nameParameter = first_name != null ?
    		new ObjectParameter("first_name", first_name) :
    		new ObjectParameter("first_name", typeof(string));
    
    	var last_nameParameter = last_name != null ?
    		new ObjectParameter("last_name", last_name) :
    		new ObjectParameter("last_name", typeof(string));
    
    	return ((IObjectContextAdapter)this).ObjectContext.ExecuteFunction<UserList>("SearchUsers", first_nameParameter, last_nameParameter);
    }

    Friday, June 8, 2012 9:42 PM
  • I found this http://stackoverflow.com/questions/4836066/entity-framework-4-unicode-problem-saving which may help a bit.

    See also

    http://msdn.microsoft.com/en-us/library/gg696309(VS.103).aspx

    may be you can apply this method to your string parameters.


    For every expert, there is an equal and opposite expert. - Becker's Law


    My blog

    Friday, June 8, 2012 10:23 PM
  • 	return ((IObjectContextAdapter)this).ObjectContext.ExecuteFunction<UserList>("SearchUsers", first_nameParameter, last_nameParameter);
    Find function USERLIST.  Your call to the proc is probably there, but could still possibly be nested deeper.
    Saturday, June 9, 2012 10:13 AM