Handling foreign characters

spireite

I've noticed that the script generated is incorrect when it comes to handling foreign characters. e.g. letters with umlauts. When the script is run, the characters are not created as letters with umlauts. Is there anything we can do to correct this? The script is applied through SQL-DMO.ExecuteImmediate method, and so a compare throws up all records as different because the characters aren't correctly handled. The database coulmns involved are not defined as unicode btw

Cheers,
Paul

Neil Davidson

Paul,

When you say the script is not generated correctly, how are you viewing the script? Are you opening it up in Query Analyzer? If so, this can't cope with the encoding that we use - you'll need to open it in notepad and then save it as UTF-16.

- Neil

spireite

I was viewing it in notepad. Loading in notepad and saving as UTF-16 is not an option in a totally automated environment. This runs daily, to provide our users (400 of them) with daily updates. Kinda defeats the object with Notepad.

Sequence is - Compare (via toolkit),
execute resulting script immediately against the database that was compared to. This is fine.

Save script, zip, and upload to server.

An application we wrote (in VB) downloads zip, unzips it, loads the SQL script created in toolkit - running against endusers database to synch it. The script is loaded and executed in SQLDMO.ExecuteImmediate method.

Any workarounds I can use, because this is going to be a big issue !

Thx

Neil Davidson

Is the application you've written in VB or VB.NET? The file saved will be in UTF-8 format which VB6 may not be able to cope with.

spireite

Sorry for the delay in responding..

The importing application is written in VB6 SP5. The reasoning behind this (though we would have preferred .NET), was that the rest of our application suite also installed at the time was not .NET (actually Gupta Team Developer). For a very small importing application, we didn't want to force the installaton of the .NET framework down users throats.

However, if VB6 is the problem, then maybe a change is required.

Neil Davidson

If you need to stick with VB6 then you might be able to read the UTF-8 data in using the ADOB.Stream class. Setting the Charset property to "utf-8" and then using ReadText should pull it in.

spireite

Interesting thought there Neil. I'll have to try it after I get back to the office in a couple of weeks after my break.

VB is not my forte, coming from 4GL background and latterly dealing purely on the database side. Originally I was using FileScriptingObject, then on request switched to a traditional OPEN FOR INPUT.

Personally, I wish I'd pushed the .NET side and dropped VB.

Cheers.