LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (January 2006, week 3)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Mon, 16 Jan 2006 08:48:16 -0500
Reply-To:   "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   "Howard Schreier <hs AT dc-sug DOT org>" <nospam@HOWLES.COM>
Subject:   Re: String Values getting truncated in Proc export of CSV

I want to point out that despite the mention of "export" in the Subject, this thread has been about the behavior of PROC IMPORT. That's important, because truncation by PROC EXPORT would be more surprising and more disturbing.

On Mon, 16 Jan 2006 04:12:15 -0800, Hari <excel_hari@YAHOO.COM> wrote:

>Art, > >Thanks for the post. > > >>You indicated changing >>the name on an informat statement, but since proc import would have >>created format and input statements as well you will have to change the >>names for all three statements. > >Im sorry, I changed everywhere, but didnt paste all my syntax in my >post as it was becoming too long. Even after changing in all three >places it wasnt working.

You are right to try to make things concise, but in this case you should miniaturize by using an example with fewer variables rather than by leaving out germane parts of the code.

> >>You indicated that the file already has names in the first row but, if you >>look at the log, proc import assigned the names to informat, format and >>input statements and actually begins reading the file at line 2. > >Im not able to understand your statement. My actual data starts from >row 2 and variable names are in row 1. I thought that when it says >"firstobs=2" it means that actual data is starting from row 2. Have I >misunderstood this? > >>My guess is that you aren't gaining anything by turning the code into a >>macro, as you can always save it and simply include it where desired, but >>I admitedly don't know all of the circumstances that may be involved. > >Actually I have many different files froma single vendor and all have >the same structure/variables and hence, I have to use a macro rather >than copy pasting the same data read code.

It's still a good idea to perfect the code first and then macro-ize.

> >I have 2 more things to report regarding truncating:- > >a) I created a string variable within Data step like > > >% Macro Create(RawSASDatasetName, ProductName); > >data &RawSASDatasetName; > set &RawSASDatasetName; > FatEProdName = &ProductName; >run; >%mend ; > >After passing the parameter of ProductName while calling the macro, the >variable FatEProdName was getting truncated. > >I had to resort to > > >% Macro Create(RawSASDatasetName, ProductName); > >data &RawSASDatasetName; > set &RawSASDatasetName; > format FatEProdName $char30. ; > FatEProdName = &ProductName; >run; > >%mend ; > >In order for no truncation. Is this normal behavoiur? Or was it a bad >practise on my part

I can't tell. If I had code and data to replicate the process on my machine, maybe I could.

> >b) The issue of truncation occured even with files which have been >created by me. I prepared an excel file containing 2 colums and 40 rows >and saved it as a CSV and after reading it the values were getting >truncated? I had to resort to using log from Proc Export for this case >as well. Im surprised as to why is it happening with so much frequency. > Please note, both my columns in this case were string data types and >sorting by length of one row wouldnt work as second column's some other >row might be of more length character wise. Does SAS know of this >problem (or is it not even considered as a problem).

SAS knows and it has been discussed here many, many times.

> >The code becomes very unweildy when we use an INFILE rather than a Proc >Export.

I think you mean Import rather than Export. Coding a DATA step allows you to declare informats and generally control the process as necessary. This can lead to success. PROC IMPORT is trouble-prone when reading from sources which do not provide metadata (as for example DBMS tables do).

> >regards, >Hari >India

Back to: Top of message | Previous page | Main SAS-L page