Hi Bruce,
Yes you are right. The import/export wizard is really no use. I have managed to solve this. Since my hosting company did not help me at all and I do not have permissions to restore my database I had to go through a very complex operation to solve this. What I had to is to script all tables and their primary and foreign keys. I had to do this in certain order. Then I built a SSIS solution with data flow tasks that pass the data. In the case of the PMMessage and Thread table I had to also do the following:
1) I created a new column with data type 'ntext' instead of the Message column which was of type 'text'. I had to delete the other column, rename the new one to the old one and then remove the keys, truncate the table and and the keys again.
2) I set this column's locale to Hebre locale.
3) In my SSIS package I created a data flow task that contains OLE DB source, data conversion transformation and OLE DB Destination -
* The data conversion converts the old 'text' column to format 'ntext'
* Both the OLE DB source and destination are defined with default code page of 1255 (represents Hebrew) in their properties. The OLE DB source is also defined to have the AlwaysUseDefaultCode as True.
Many other combinations I have tried caused the database to have either corrupted text, or actually even worse to have all the values in the database in proper Hebrew while on the website they did not appear correctly.
If I had permissions to restore my own database or if my hosting company would have agreed to do this for me all that work of literally days would be redundant...
Thank you for your reply,
Noy.
Edited by noyshani - 04 March 2011 at 11:40pm