04-16-2015 03:15 PM
Hi, this is my first post so apologies if i do this wrong.
What i am trying to do is straight forward enough, I am working in two environments, one is using SAS EG with SAS 9.4 and has utf-8 encoding, the other is regular SAS 9.1.3 using wlatin1 encoding. I need to create an .XPT file (so a transport file) from a SAS data set, in the 9.4 environment but make sure the .XPT uses the wlatin encoding. I need this so i can read it in correctly in the SAS 9.1.3 environment, and make sure the extended characters are read correctly in the SAS 9.1.3 wlatin1 environment. So this is what I have so far.
This is my code in the SAS 9.4 UTF-8 environment
** My SAS Data set I want to convert to an XPT file;
data adsl (encoding = "wlatin1");
** Some extended characters;
length ex_chars $20;
if trt01pn = 1 then ex_chars = "é";
if trt01pn = 3 then ex_chars = "µ";
if trt01pn = 2 then ex_chars = "±";
** Where I want to XPT file to go;
libname xptfile xport "\\server\XPT\adslwlatin1_xpt.xpt" encoding = "wlatin1";
** Export XPT. File;
data = adsl
Now here is my code to then convert this SAS 9.4 .XPT file into SAS 9.1.3 data set.
** XPT file location;
** SAS file location;
** Import XPT into SAS file;
infile = xptfile
library = sasfile;
However since my 9.4 environment uses the UTF-8 encoding it seems to save the XPT. file as a UTF-8 encoded XPT file. Which in turn causes the XPT file once import into SAS 9.1.3 using the wlatin encoding to produce the following warning.
WARNING: The transport file is from an earlier SAS release, or 9.1.3 without the corresponding hotfix. If this transport file contains non-English data, there may be problems importing national characters. If problems do occur, the transport file will
Which I understand, and even though i define the XPT file location in SAS 9.4 to use the wlatin1 encoding, it still seems to save the XPT file as a UTF-8 encoded file.
So my question.
Is there anyway to create the XPT file in SAS 9.4 (which uses the UTF-8 encoding) but store the XPT file as a wlatin1 encoded file?
NOTE: This needs to be done with the CPORT procedure.
Thank you in advancedf-8
04-16-2015 03:40 PM
04-16-2015 04:20 PM
No still produced the warning and the same issue with the extended characters. Since the transport file uses the encoding UTF-8 the extended characters in the data set in SAS 9.4 data set
Transcode to double byte characters in the SAS 9.1.3 wlatin1 environment, and look like this in the data set
04-16-2015 03:52 PM
Base SAS(R) 9.4 Procedures Guide, Third Edition it is documented that behavior of cport/cimport. Not being compatible in encodings. Even an import of latin1 into utf8 is failing.
Another is going form a newer to older release (regression) is not possible Base SAS(R) 9.4 Procedures Guide, Third Edition The weirdest one was seeing it checking that including the fix-level.
04-16-2015 04:15 PM
Thank you for the info, after having a read it looks like the encoding of the transport file is basically decided by the encoding setting of SAS session? In my case in SAS 9.4 uses the encoding utf-8, therefore so will my transport file
04-16-2015 04:36 PM
Yep what you are seeing is the proof there has been utf-8 chars stored in the transportfile. Those é µ ± are not part of the 7bit ascii and must be get a mbcs representation in a utf8 session. That are those Ã you are seeing.
That is getting into a disruption in many ways as 1 byte ^= 1 char it now 1 char = 1-4 bytes. The only way out van be using CEDA (sas7bdat) or SAS-connect (9.4 new functionality) SAS(R) 9.4 Language Reference: Concepts, Fourth Edition
04-16-2015 04:43 PM
Hi, thanks again for your information. Yeah i understand the multi byte character sets (MBCS) issue.
The SAS CONNECT method you mentioned, does this still create XPT files? The main issue I need to send UTF-8 encoded XPT files to someone with a wlatin1 encoded environment, I can only seem to find that XPT files encoding is determine by my SAS session encoding option. Is there a way to change the SAS session encoding?
04-16-2015 04:59 PM
The SAS connect uses his own intermediate files. Moving and Accessing SAS(R) 9.4 Files, Second Edition In the CEDA link also Socket mode (SAS/connect) is mentioned. The mentioned goal with CEDA is encoding issues.
The engine can be kept as a 9, the directory limitation is telling Windows and/or Unix. The exception is classic bound mainframe libraries, not your case.