>After having done more research on this, I have additional details.
>
>I am not sure if this is a limitation of the SQLClient provider. Maybe someone can elaborate more on the topic.
>
>I have the following declarations:
>
>
> Public oDataSet As DataSet = Nothing
> Private oCommand As IDbCommand = Nothing
> Private oDataAdapter As IDbDataAdapter = Nothing
> Private oDataParameter As IDbDataParameter = Nothing
>
>
>I am passing a parameter to the data object. That parameter is a string. The string contains on the 8th character a character which is above the ASCII 255 standard. In my case, the Prime character is recognized as Unicode 8242. Up to my data class, I can see that the function ASC() returns 39 for that character and that the function ASCW() returns 8242 for that character. This is up to that level:
>
>
> oDataAdapter.SelectCommand = oCommand
>
>
>At this point, oCommand does contain a parameter and when I show its value, I can see that ASC() and ASCW() return as mentioned in the above paragraph.
>
>Now, I need to find where this is not working. Down below, I have this code:
>
>
> oDataSet = New DataSet
>
> Using loSQLConnection As New SqlConnection(lcConnectionString)
> oCommand.Connection = loSQLConnection
> oDataAdapter.Fill(oDataSet)
> End Using
>
>
>The SQL select command cannot find the record despite the fact that the parameter I checked out is in fact containing the proper Unicode character and that is what is in the record. So, is it a limitation of the SQLClient provider, the IDb approach or else?
>
>I am pretty sure SQL Server should support such a search. Otherwise, it would be really weird that we could store such character in a field but not able to search it.
ASC() is 39 ? That is 0x27 in hex and is equal to the apostrophe
http://www.fileformat.info/info/unicode/char/2032/index.htm also known as single quote
Gregory