- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
How can I troubleshoot this error message?
NOTE: Data file EGFR.REPATED_MEASUREMENTS.DATA is in a format that is native to another host,
or the file encoding does not match the session encoding. Cross Environment Data Access
will be used, which might require additional CPU resources and might reduce performance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
1) Could be the encoding of that sas table is different from your local sas session. You can change it like :
proc datasets library=work nodetails nolist;
modify have/ correctencoding='utf8';
quit;
2)Could be OS that sas table be generated is different from your local PC OS. You can change it like :
data have(outrep='linux_32');
set sashelp.class;
run;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Do I need to add either of these lines in the beginning of my SAS code?
Thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
It might be encoding but it could also be due to the architectural difference between machines. If eg. your dataset was created on AIX or hp-ux and then the .sas7bdat file was moved over to Windows or Linux you will see this. It is due to the different byte order of the processor between the native OS and the current one. Have a look at https://nl.wikipedia.org/wiki/Endianness.
My first step would be to investigate the lifespan of the dataset from creation to where it is now. In any case you will be able to reconstruct the table to a native shape by copying it as KSharp suggested. Hope it's not a large one.
Hope this helps,
- Jan.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
This is NOT an ERROR message. It is an informational note, telling you that the data set your using was created in a format that was native to another host operating system. SAS will still read the data. IF you experience performance issues (which may happen, but is not guaranteed to happen), then you might want to pursue "fixing" the dataset. But this is NOT an ERROR. SAS Errors start with ERROR: and are usually displayed in RED. Notes are informational, start with NOTE: and Warnings are more serious, and start with WARNING:
cynthia
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I meet the same question. Have you settle it? Can you help me? Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
If you are getting the SAME message, then the answer is the SAME, as well.
Cynthia
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Hi, would you also get this error when running programs created using Windows 8 PRO and now running Windows 10?
Thanks for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Cynthia
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
I have an odd case where the environments are the same and I still get the CEDA note. Any ideas? I know it's an informational message - is there any reason for concern?
Thanks in advance!
Here are the details.
Data originated on machine 1 and then transferred to machine #2 via SCP.
PROC CONTENTS from original dataset on Machine #1:
Data Set Name |
LANDPROD.RTL_SML_APP |
Observations |
59071485 |
Member Type |
DATA |
Variables |
18 |
Engine |
V9 |
Indexes |
0 |
Created |
05/31/2018 15:44:43 |
Observation Length |
97 |
Last Modified |
05/31/2018 15:44:43 |
Deleted Observations |
0 |
Protection |
|
Compressed |
CHAR |
Data Set Type |
|
Reuse Space |
NO |
Label |
|
Point to Observations |
YES |
Data Representation |
HP_UX_64, RS_6000_AIX_64, SOLARIS_64, HP_IA64 |
Sorted |
NO |
Encoding |
latin1 Western (ISO) |
|
|
Engine/Host Dependent Information |
|
Data Set Page Size |
65536 |
Number of Data Set Pages |
86075 |
Number of Data Set Repairs |
0 |
Filename |
/data/landing/rtl_sml_app.sas7bdat |
Release Created |
9.0401M4 |
Host Created |
SunOS |
Inode Number |
824 |
Access Permission |
rw-rw-r-- |
Owner Name |
sassrv |
File Size |
5GB |
File Size (bytes) |
5641076736 |
PROC CONTENTS from original dataset on Machine #2
Data Set Name |
LANDMODL.RTL_SML_APP |
Observations |
59071485 |
Member Type |
DATA |
Variables |
18 |
Engine |
V9 |
Indexes |
0 |
Created |
05/31/2018 15:44:43 |
Observation Length |
97 |
Last Modified |
05/31/2018 15:44:43 |
Deleted Observations |
0 |
Protection |
|
Compressed |
CHAR |
Data Set Type |
|
Reuse Space |
NO |
Label |
|
Point to Observations |
YES |
Data Representation |
HP_UX_64, RS_6000_AIX_64, SOLARIS_64, HP_IA64 |
Sorted |
NO |
Encoding |
latin1 Western (ISO) |
|
|
Engine/Host Dependent Information |
|
Data Set Page Size |
65536 |
Number of Data Set Pages |
86075 |
Number of Data Set Repairs |
0 |
Filename |
/sasdata/ally_fraud/fcm/data/landing/rtl_sml_app.sas7bdat |
Release Created |
9.0401M4 |
Host Created |
SunOS |
Inode Number |
176988 |
Access Permission |
rw-rw-r-- |
Owner Name |
sas |
File Size |
5GB |
File Size (bytes) |
5641076736 |
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Copying a .sas7bdat file via SCP is binary and won't change the encoding. So I'd hope for a Proc Contents to show the same information when run on source and target environment.
What the CEDA message tells you is that SAS in the target environment would natively create the .sas7bdat file a bit differently and that reading the .sas7bdat file in the source version will create a bit of overhead.
Below code run on your target machine #2 will re-create the table. Run your proc contents after this code and observe the differences.
data LANDMODL.RTL_SML_APP;
set LANDMODL.RTL_SML_APP;
run;
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Patrick,
That provided the answer. While both servers are running the same OS and SAS release levels, it turns out that one was running with encodnig set to LATIN1 and the other was set to UTP-8.
Time to have a talk with my adimns about this one...
Many Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- RSS Feed
- Permalink
- Report Inappropriate Content
Oddly, Patrick's solution didn't work for me.
Here's what *did* work:
%MACRO Fix_Table_Encoding(SrcTbl, Test=Y); proc contents data = &SrcTbl; run; %IF &Test = Y %THEN %GOTO AllDone; proc sql; CREATE TABLE Temp AS SELECT * FROM &SrcTbl; DROP TABLE &SrcTbl; CREATE TABLE &SrcTbl AS SELECT * FROM Temp; quit; proc contents data = &SrcTbl; run; %AllDone: %MEND Fix_Table_Encoding; %MACRO FixHelpers; %LOCAL Tables TblCount tnx TblName; %LET Tables=; LIBNAME HLP META LIBRARY = "IE Reporting Helpers HELPERS" metaout = data; proc sql; SELECT cats('HLP', '.', MEMNAME) INTO : Tables separated by '|' FROM SASHELP.VSTABLE WHERE LIBNAME = 'HLP' ; quit; %LET TblCount = %sysfunc(countw(&Tables, |)); %DO tnx = 1 %TO &TblCount; %LET TblName = %scan(&Tables, &tnx, |); %PUT Working table &TblName; %Fix_Table_Encoding(&TblName, Test=N); %END; LIBNAME HLP CLEAR; %MEND FixHelpers; %FixHelpers;