R help - Dec 2002 - Part II Re: read.ssd {foreign} (Reading a permanent SAS d ataset into an R data frame)

Scot,

Thanks for the additional information.  On further
reflection... whether one uses SAS PROC EXPORT or uses
a SAS LIBNAME yourfile XPORT 'yourpathname';
statement, an intermediate file is created in either
case.  As far as experience tells me now, PROC EXPORT
is a far superior choice, because variable names do
not get truncated and you only have to deal with
reading in a simple text file, not a propritary funky
SAS Transport File, which seems to complicate matters
not help them.

My future use of R is still in the works, but my boss
is impressed with the R graphics, so I am going to
continue to press on developing intelligent ways to
read data from different systems in addition to
solving statistical problems.  BTW, I am a novice in
all these approaches and appreciate all the useful
feedback I can get for making these decisions on how
to best use R.

Thanks Scot,

Stephen

--- Scot W McNary <smcnary at fellspt.charm.net>
wrote:
> 
> Stephen,
> 
> Good questions. I didn't know the answers so did a
> little experiment.
> The long variable names are apparently a problem for
> the spss engine (see
> highlighted log note--other comments below):
> 
> 
> 41   * using SAS ;
> 42   libname check xport 'e:\testing.xpt' ;
> NOTE: Libref CHECK was successfully assigned as
> follows:
>       Engine:        XPORT
>       Physical Name: e:\testing.xpt
> 43
> 44   data a;
> 45
> 46   do i = 1 to 10 ;
> 47          xnamedlongerthan8char = 1 + i ;
> 48          yalsonamedlongerthan8char > 50/xnamedlongerthan8char ;
> 49          output;
> 50          end;
> 51
> 52   run;
> 
> NOTE: The data set WORK.A has 10 observations and 3
> variables.
> NOTE: DATA statement used:
>       real time           0.00 seconds
> 
> 
> 53
> 54   data check.a ;
> 55   set a ;
> 56
> 57   run;
> 
> ERROR: The variable name xnamedlongerthan8char is
> illegal for the version
>           
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 6 file CHECK.A.DATA.
> 
> 
> NOTE: The SAS System stopped processing this step
> because of errors.
> WARNING: The data set CHECK.A was only partially
> opened and will not be
> saved.
> NOTE: DATA statement used:
>       real time           0.10 seconds
> 
> Taking a browse of the manual didn't give much
> enlightenment as to why the
> transport engine doesn't like long variable names,
> except that since the
> xport engine can also be used to 'regress' datasets
> from version 8 to
> version 6, which doesn't support long variable
> names.  SAS may have
> decided that version 6 is the lowest common
> denominator for transport
> format files and so all formats devolve to that.
> 
> I wonder if your question about preserving long
> variable names in
> transport format would be worth a post to the SAS-L
> list (or
> comp.soft-sys.sas)?  There's probably a PROC SQL
> solution out there
> somewhere...
> 
> I don't know about the size of the dataset issue
> either, although I rarely
> work with files that either SAS or R would complain
> about.  The long
> variable name issue is problem when it comes to the
> xport engine, which is
> why in retrospect I've stuck with the PROC EXPORT
> solution, since I've
> come to really rely on long variable names in my
> day-to-day work with SAS.
> 
> The PROC EXPORT solution has worked pretty well for
> me so far and doesn't
> seem to take too much extra programming on either
> the SAS or R end, at
> least when I've used it. That actually might be a
> pretty decent
> workaround, except for the extra dataset problem you
> mention.
> 
> Thought I had something that would work for you, but
> turned out not to be
> all that helpful.  Sorry.
> 
> One other thought is that in Frank Harrell's Design
> library there is a
> function called 'sas.get' that will start a sas job
> from within R, write
> out the file from within a dataset, and read it into
> R.  This might get
> around the long variable name truncation since it
> never calls the XPORT
> engine or uses PROC CPORT.  I've not ever used it
> however, so can't
> testify on it's use.  In addition, the call to SAS
> might need some
> configuring.  Frank Harrell often posts to the
> R-help list and has been
> extremely helpful in answering questions, if you
> wanted to try that route
> out and ran into trouble.
> 
> Scot
>