Data file is in a format that is native to another host

[mantubiradar19]

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.

[Ksharp]

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;

[mantubiradar19]

Do I need to add either of these lines in the beginning of my SAS code?

Thank you 

[jklaverstijn]

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.

[Cynthia_sas]

Hi:
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

[mantubiradar19]

Thanks for the clarification!

[scy]

I meet the same question. Have you settle it? Can you help me? Thank you!

[Cynthia_sas]

Hi:
If you are getting the SAME message, then the answer is the SAME, as well.
Cynthia

[telsadl]

Hi, would you also get this error when running programs created using Windows 8 PRO and now running Windows 10?

Thanks for your help.

[Cynthia_sas]

It is possible that data created under one version of Windows might give the same error under another version of Windows, especially if the "bitness" was different -- 32 bit vs 64 bit.

Cynthia

[KenMac]

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

[Patrick]

@KenMac

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;

[KenMac]

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!

[JimmyJoeBob]

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;