I am facing one common issue which was posted a lot of times here. I have tried some of the the solutions suggested but nothing solved my issue.
1. I am reading arabic data from Oracle DB, from blob column.
2. I am converting this data to String using UTF-8 charset. like :
String temp = new String(data.getMessage().getBytes(),"UTF-8");
3. I am writing this temp String in txt file which is properly showing arabic data.
4. I am connecting to SQL server 2005 DB using below property set
and I am using com.microsoft.jdbc.sqlserver.SQLServerDriver driver.
5. I am setting this temp String in query statement (which is a call to Stored procedure to insert data in SQL server 2005) in two ways :
a. directly like proc_stmt.setString(2,temp); OR
b. on doing encoding proc_stmt.setString(2,new String(temp.getBytes(),"UTF-8"));
6. I am calling stored procedure with this data which inserts this arabic message in varchar field of sql server 2005 DB.
After all this process, it is inserting ??????? in sql server instead of arabic message.
When we directly call stored procedure from sql server query analyzer/console it is inserting proper arabic message.
But when I use java program to do that, It is inserting ??????.
for similar kind of issue.
I have refered this and set connection property charSet to UTF-8. but it didn't work for me.
Kindly help regarding this issue.
Prompt help will be really helpful.
Well, that's an awfully complicated test of SQL Server. There's a lot of other things that might go wrong -- especially your #2 which looks a lot like a cheap hack which might occasionally work if you're lucky but is usually a recipe for disaster.
So why don't you do a simpler test? Put a constant string into a test program -- make sure to use Unicode escapes rather than relying on having a correct encoding in your source code -- and try writing it to SQL Server. Also make sure you're using the right parameter name for the charset. (I have no idea what's correct or even if there is one.) You should only accept solutions where #5a works, not that ugly hack which is #5b.