Date: Thu, 18 Dec 2008 14:33:10 -0600
Reply-To: "./ ADD NAME=Data _null_," <iebupdte@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: "./ ADD NAME=Data _null_," <iebupdte@GMAIL.COM>
Subject: Re: Space and Double-tilda( ~~) delimited file
Content-Type: text/plain; charset=ISO-8859-1
Add this statement to your data step...
If the OP has 9.2 the DLMSTR does exactly what is called for.
The DLMSTR= option for the INFILE statement is available beginning in
SAS 9.2. DLMSTR stands are "delimiter string'. This option enables
programmers to specify a multi-character string as a delimiter. For
example, DLMSTR="-/-" treats these three characters, in this order, as
a delimiter. Prior to this option, each individual character specified
in the DLM= option would have been treated singularly as a delimiter.
The DLMSTR= option supports specifying a character variable after the
equal sign. The value in the variable is used as the delimiter.
DLMSTR= is also supported on the FILE statement, enabling users to
write data with multi-character string delimiters.
On 12/18/08, Shiling Zhang <firstname.lastname@example.org> wrote:
> On Dec 18, 2:46 pm, baymanl <baym...@gmail.com> wrote:
> > Hi all,
> > We obtained some datasets from a third party and the data are
> > delimited with space-tilda-tilda ( ~~), and some (but not all) missing
> > entries are underscores (_). I cannot import them into SAS properly.
> > What I have tried:
> > 1 - importing directly into SAS. If I do this by indicating the
> > delimiter is " ~~" then I get one extra column for each second tilda.
> > (160 variables instead of 80). Also many errors due to ~ and _'s.
> > 2 - import to Access -> import to SAS. I get better structure, only
> > couple empty columns, but almost all the variables are 255 character
> > long.
> > 3 - open the data in a text editor -> find/replace " ~~" with commas,
> > replace _ with space -> import to SAS as CSV. It's the most
> > cumbersome, but seems like the best way. Except, I cannot indicate
> > some variables are in fact texts (patients ID numbers, etc), and they
> > are in numeric format after importing which creates problems with the
> > current SAS codes.
> > Have you had any similar problem, and how did you manage importing?
> > Thanks a lot.
> > L
> You may consider to write your own inport pgm. Here is an example and
> you can modify it for your use.
> data t1;
> length x $1;
> infile cards delimiter=' ~' truncover;
> input x y z;
> 1 ~~2
> 1 ~~_ ~~3
> 1 ~2 ~~3
> 1 2 3
> proc print; run;