Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m using an Oracle database with a collation different to my OS language. I’m accessing the database using the ODBC driver. When I prepare a statement (e.g. a ‘select * from x where=?’), that involves special non-ASCII characters supported by the DB’s collation, I’m finding the data row with the characters. When I execute the select directly with the argument in the sql string, the data row isn’t found.
Pure guess on my part, but it may be because your client computer isn’t encoding the sql string with the argument written into it correctly. I think that if your client is set to a different regional setting than the DB collation, the character array containing the select statement that gets sent to Oracle would contain ‘incorrect’ bytes where the original funky characters were located – Oracle would interpret these as some character other than the one you originally sent (causing the row to not be found).
Is there any reason you can’t just use the parameterized approach (since it is working correctly)?