Schema Compare Character Set

teltest

I am running SchemaCompare from a command line.  The command is:

sco32.exe /source username/password@DB{MRS}  /target .{MRS} /i:sdwqgvar /deploy /deployallobjects /report:"MRSPROD.html" /reporttype:Interactive /verbose > output.txt

This compares our database to a set of files (previously produced by SchemaCompare).

Unfortunately, this produces files where the £ sign is not saved properly in the file.
I attach a file showing the difference between a file saved by SchemaCompare and a file saved directly from PL/SQL Developer:



The file on the left has been produced by SchemaCompare.

Is this something that can be resolved?

rguser12

I managed to replicate locally the situation with a pound sign.

In fact TextPad does not do as well with encoding support compared to modern editors (for example, Notepad ++)

If you want to execute correctly the script generated by Schema Compare set the environment variable NLS_LANG to the value of .AL32UTF8 before running Sql Plus.

SET NLS_LANG=.AL32UTF8

Then execute the script.
Hope this helps.

rguser12

What is the encoding of your files? 
I get such a result when I convert a file from UTF-8 encoding to ASCII. ( '£' =>  '£')

teltest

rguser12 said:

What is the encoding of your files? 
I get such a result when I convert a file from UTF-8 encoding to ASCII. ( '£' =>  '£')

The file generated from Schema Compare appears to be "UTF-8" . It is also produced using Unix (LF) end of line characters.
I believe that we need it to be "ANSI" using Windows (CR LF) for End of line.

rguser12

Can you describe step by step what you do?
I will try to recreate this situation in my environment.

teltest

I am using Windows 10.
I use Schema Compare to Create a Script Folder. I follow all the default steps - this creates a folder structure named after the schema. This folder contains further folders (for each object type) - these now hold scripts for each of the objects.

I have a Package Spec that contains a constant which is a pound sign '£'. 

c_sterling             CONSTANT VARCHAR2(1) := '£';

The file that has been produced seems to have changed this to '£' - This is only visible in certain editors (e.g. TextPad). However, f I run this script back into the database (for example using SQL Plus) - this line is changed to:

c_sterling             CONSTANT VARCHAR2(1) := '£';

This now means that when this constant is used - it will fail because it has a length of 2 and not 1 as it has been defined.

As another annoyance is that the files that Schema Compare produces seem to have a line ending of just LineFeed then the code is unreadable in some editors (such as Notepad).

teltest

rguser12 said:

I managed to replicate locally the situation with a pound sign.

In fact TextPad does not do as well with encoding support compared to modern editors (for example, Notepad ++)

If you want to execute correctly the script generated by Schema Compare set the environment variable NLS_LANG to the value of .AL32UTF8 before running Sql Plus.

SET NLS_LANG=.AL32UTF8

Then execute the script.
Hope this helps.

Many thanks for your help. You are very generous with your time.

I think that the problem for me is that the file being produced by SchemaCompare is not in a format that I would like. I think also that this is something that I just have to live with. The issue itself could be as a result of the database being housed on a Linux server and therefore the script could be in a specific encoding or character set.  I will probably get round that by running some Powershell Script on the output.