BookmarkSubscribeRSS Feed
craig159753
Quartz | Level 8

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");

        set adam.adsl;

        ** 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 = "±";

run;

**====================================================================================;

** Where I want to XPT file to go;

libname xptfile xport "\\server\XPT\adslwlatin1_xpt.xpt" encoding = "wlatin1";

** Export XPT. File;

proc cport

        data = adsl

   file="\\server\XPT\adslwlatin1_xpt.xpt";

run;



Now here is my code to then convert this SAS 9.4 .XPT file into SAS 9.1.3 data set.


** XPT file location;

libname xptfile xport "\\server\XPT\adslutf8_xpt.xpt";

** SAS file location;

libname sasfile "\\server\XPT\SASFILE";

** Import XPT into SAS file;

proc cimport

   infile = xptfile

        library = sasfile;

run;


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

7 REPLIES 7
SASKiwi
PROC Star

I think you need to use a FILENAME statement with PROC CPORT:

filename xptfile "\\server\XPT\adslutf8_xpt.xpt" encoding = "wlatin1";

proc cport

        data = adsl

   file=xptfile;

run;

craig159753
Quartz | Level 8

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

é

µ

ñ

jakarman
Barite | Level 11

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.

---->-- ja karman --<-----
craig159753
Quartz | Level 8

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

jakarman
Barite | Level 11

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 

---->-- ja karman --<-----
craig159753
Quartz | Level 8

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? 

jakarman
Barite | Level 11

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.

---->-- ja karman --<-----

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

What is Bayesian Analysis?

Learn the difference between classical and Bayesian statistical approaches and see a few PROC examples to perform Bayesian analysis in this video.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 7 replies
  • 5489 views
  • 3 likes
  • 3 in conversation