Problem with encoding in c# application (SaS)

[gneccao]

Hi,

i have a dll to connect and execute commands in SaS, i´ve had use this dll for a long time, but i never needed to import a text with brazilians symbols (ã,ç , õ).

I have tried to import that type of data, but when i do that, the dataset that is the result.

I try to find the solution to change the default language or use encode (iso-8995-1), but i cannot find anything that can help me.

Has someone had this problem so far? Or can help me with the solution?

PS: Sorry if i post in the wrong Location.

Thank you,

Raphael Gnecco

[ChrisHemedinger]

Can you be more specific about the DLL you're using?  Is it a custom task for SAS Enterprise Guide? Where did it come from?

SAS has encoding nuances -- usually we recommend a UTF-8 encoding for your SAS session.  But .NET (C#) also has encoding directives when reading/writing text files.  Your DLL (assuming it's a custom task) might have a limitation here.

[gneccao]

@ChrisHemedinger,

I use a dll where createa ObjectByServer,

SASObjectManager.IObjectFactory2 obObjectFactory = new SASObjectManager.ObjectFactoryMulti2();
            SASObjectManager.ServerDef obServer = new SASObjectManager.ServerDef();
            obServer.MachineDNSName = Host;
            obServer.Protocol = SASObjectManager.Protocols.ProtocolBridge;
            obServer.Port = Port;
            obServer.ClassIdentifier = "440196d4-90f0-11d0-9f41-00a024bb830c";

            _workspace = (Workspace)obObjectFactory.CreateObjectByServer(
                Name, true,
                obServer,
                // if trying IWA, pass null in
                // otherwise try supplied credentials
                string.IsNullOrEmpty(UserId) ? null : UserId,
                string.IsNullOrEmpty(Password) ? null : Password);

            objectKeeper.AddObject(1, Name, _workspace);

_workspace.LanguageService.Submit(codigo);

In the .NET, i was already using the enconding (iso-8995-1). But i think the problem was i don´t have a custom LanguageService, i was using the default, and i believe the default is using UTF-8.

i cannot using UTF-8, because the Brazilians symbols, most of the is part of the Company name.

[RW9]

Well, not really knowing anything about the process its hard to say (i.e. whats being called).  But SAS handles encodings either by system startup or in some cases you can push that onto the code:

http://documentation.sas.com/?docsetId=nlsref&docsetTarget=n0utx4w7x4exijn1wt7pk0srrxz5.htm&docsetVe...

If you have special characters, then its likely you will want UTF8 or 16 as your character set, this tends to be defined at a system level though, so you would need to discuss with your SAS group.  You may be able to add the bit from the link I post into the code you are calling though.  Again discuss with someone who can actually look at the issue as a whole.

[gneccao]

@RW9,

 I´m using the ENCODING="LATIN1",  i already try to but, "UTF-8" and "iso-8995-1", but doesn´t change the result.

DATA PROTOCOL;
FORMAT
PROTOCOLO $CHAR10.
ASSUNTO $CHAR175.
ENVIADOPOR $CHAR54.
DATAEMAIL DATETIME18.;
INFILE '/DESENV/BoasVindas/file.txt'
LRECL=243
ENCODING="LATIN1"
TERMSTR=LF
DLM='$'
MISSOVER
DSD ;
INPUT
PROTOCOLO : $CHAR10.
ASSUNTO : $CHAR175.
ENVIADOPOR : $CHAR54.
DATAEMAIL : ?? ANYDTDTM19.;
RUN;

[ChrisHemedinger]

I think you might need to set your SAS session encoding to UTF-8.  That can be set only at the session start from the command line or the SASV9.cfg.  Your .NET code that launches the server can't control this -- it has to be set in the Workspace options where the SAS application workspace is defined.  It's not just a simply matter of specifying encoding preferences -- the process has to load different modules that can handle the multibyte nature of UTF-8 data.

[gneccao]

@ChrisHemedinger,

The problem is, in the Enterprise Guide it´s works perfectly. The problem occurs only when use the dll.

[ChrisHemedinger]

@gneccao What's your set up?

Where is the data file?  On your local machine or on the remote SAS session?

Where does SAS run?  Is it a remote server?

How does the data file get to the SAS session?  Does your C# code move it there or is it already in place when the DLL process is running?

If the C# code is reading the data file and copying it to SAS, then that's where the encoding could be lost.

If both the DLL and SAS EG are working with the file already in place on the SAS session location, then are you sure the SAS session is launched with the same arguments?  Check the encoding properties of the server in EG -- look at the Servers list, right-click on the server name, select Properties, Software tab.  That will show the encoding.

[gneccao]

Where is the data file? On your local machine or on the remote SAS session?
   - I create the file in local machine.

Where does SAS run? Is it a remote server?
   - Yes, it´s a remote server

How does the data file get to the SAS session? Does your C# code move it there or is it already in place when the DLL process is running?
   - I create the file in c# code and use WinSCP to transfer to SaS host.

If the C# code is reading the data file and copying it to SAS, then that's where the encoding could be lost.
   - I don´t think the problema is here, because i create a file using the encode, then i transfer to SaS.

If both the DLL and SAS EG are working with the file already in place on the SAS session location, then are you sure the SAS session is launched with the same arguments? Check the encoding properties of the server in EG -- look at the Servers list, right-click on the server name, select Properties, Software tab. That will show the encoding.

[ChrisHemedinger]

When you use WinSCP to transfer the file, are you transferring as a text file or as binary?  If as text, the encoding might be adjusted as part of the transmission.  EG transfers the files (usually) as binary to avoid encoding mismatches.

[gneccao]

I´m using TransferMode.Automatic, so probably is going with text. Do you think i change to binary might resolve the problem?.

I gonna test and reply the result.

[gneccao · Accepted solution]

Changing the TransferMode to Binary, appears to solve my problem.

Thank you for the Help.