April 12, 2013 at 3:51 am
If I understand correctly, when looking at the same table with different clients, you can see the japanese characters in one, but not in the other? Doesn't that mean the data is in the table, but one client can't handle it properly, so it's a client issue?
April 12, 2013 at 7:57 am
nick.mcdermaid (4/12/2013)
If I understand correctly, when looking at the same table with different clients, you can see the japanese characters in one, but not in the other? Doesn't that mean the data is in the table, but one client can't handle it properly, so it's a client issue?
Sort of, but not exactly. It was more an issue of the characters converting to question marks from one staging table to another (columns changing from nvarchar to varchar).
The 'correct' data shows as rectangles in SSMS 2005, and Kanji in 2008. So that part is client related.
April 12, 2013 at 8:23 am
erikd (4/11/2013)
The other fields it's occurring in are first name, last name, and company name. Crud.
It should be a quick fix to the cursor declaration I showed above so those columns are generated as NVARCHAR.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
April 12, 2013 at 8:38 am
opc.three (4/12/2013)
erikd (4/11/2013)
The other fields it's occurring in are first name, last name, and company name. Crud.It should be a quick fix to the cursor declaration I showed above so those columns are generated as NVARCHAR.
You were dead on. I changed and tested the script, and everything works beautifully. Thank you for your time.
Are you aware of a way to write text files as Unicode? The 'default' seems to be ANSI.
Actually, I'm going to start a new thread for that, it's a distinct topic with its own stored procedure.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply