strange way of doing export

[Ronein]

Hello

I found this code in my work.

As I see this code is doing export of the table .

I want to ask you what is this way of creating export?

It is my first time that I see it.

Can we also control style of exported table here?

what is the name of this method of exporting?

data _null_;
set  output_tbl&mon.    end=EFIEOD;
%let _EFIERR_ = 0; 
%let _EFIREC_ = 0;  
file "Path" delimiter=',' DSD
DROPOVER lrecl=32767;
format score best12. ;
format customers&dec. best12. ;
format obligation&dec. best12. ;
format allowance&dec. 15.2 ;
format customers&mon. best12. ;
format obligation&mon. best12. ;
format allowance&mon. 15.2 ;
if _n_ = 1 then        
do;
put
'Score'
','
'Customers DEC'
','
'Obligation DEC'
','
'allowance DEC '
','
'Customers Current month'
','
'Obligation Current month'
','
'allowance  Current month'
;
end;
do;
EFIOUT + 1;
put score @;
put customers&dec. @;
put obligation&dec. @;
put allowance&dec. @;
put customers&mon. @;
put obligation&mon. @;
put allowance&mon. ;
;
end;
if _ERROR_ then call symputx('_EFIERR_',1);  
if EFIEOD then call symputx('_EFIREC_',EFIOUT);
run;

[RW9]

Its just writing data out to a plain text file.   This:

file "Path" delimiter=',' DSD
DROPOVER lrecl=32767;

Is showing the filename, and that the file is to be comma delimited.

This produces the header row:

put
'Score'
','
...

This writes the data:

put score @;
put customers&dec. @;
put obligation&dec. @;
...

The @ means hold the line pointer, i.e. so all items get written to the same row.

Its an oldschool way of writing data to files, preceding proc report, tagsets etc. which are layers on top of the file writing.

We used to write patient profiles outputs using this technique - though a fair bit more complicated, using algorithms to position text and what not.  Now its all BI tools and fancy pants R outputs.

[Kurt_Bremser]

Looks a lot like code taken initially from the log of a proc export run. Use of _EFIERR and _EFIREC macro variables is typical.

[Ronein]

Thanks.

So ,do you prefer to use proc export (which is much shorter code)?

[andreas_lds]

---

@Ronein wrote:

Thanks.

So ,do you prefer to use proc export (which is much shorter code)?

---

This is the important difference between proc import and proc export: avoid using proc import if you can, but use proc export as long as you don't need some really fancy text-files.

[Kurt_Bremser]

---

@Ronein wrote:

Thanks.

So ,do you prefer to use proc export (which is much shorter code)?

---

Unless you need some fancy look for the external file, proc export is the way to go. Since the source is well controlled (a SAS dataset), there are no ambiguities for the structure of the output. As long as the dataset keeps its structure, the external file will look the same.

If you need only some columns, just use a keep= dataset option.

Proc import, OTOH, works from an undefined source and needs to make guesses about the underlying structure, so the result will not be consistent; that's why an explicitly written data step is preferred.

[Reeza]

---

@Ronein wrote:

Thanks.

So ,do you prefer to use proc export (which is much shorter code)?

---

That's true in this case, but not always. From a 'short' perspective you can write a data step to export that is shorter if you wanted. 

They're both tools that you can use. One is simpler (PROC) and the other provides more control - if you wanted to do a calculation in the same step, or customize the output with different lines for a single observation. 

[ballardw]

---

@Ronein wrote:

Thanks.

So ,do you prefer to use proc export (which is much shorter code)?

---

It depends on what is needed. Proc export without a little adjustment to the code always exports all variables an you don't have any control over the order of variables in the output and the values are exported using the variables default formats.

If you need to change the order or the formatted appearance of variables then proc export may not be what you want. Then you could do something similar as shown based on Proc Export code but modified to only have the variables in specific order.

These days I would likely use ODS CSV and Proc print instead of going through the data step if there were no additional variables needed.

And NOT at all strange. I wrote a lot of that sort of data step code early in my SAS career as I was working with a group of modelers that needed input files in very specific layouts so that the FORTRAN code they were writing could read the files. If you ever work with FORTRAN you will find that the input from external files is not anywhere near as flexible as SAS and writing to their input standards for the input files was much more robust then changing the code to read the input.