PROC IMPORT Bug in 9.2 TS2M0
in [SAS]
|
From: Deborah Testa on 1 Oct 2009 13:26 FYI: My years-old PROC IMPORT code broke in 9.2 TS2M0. Here's an explanation and a suggested work-around from SAS tech support: The algorithm to determine if a value is a date, datetime or time was changed in SAS 9.2. Unfortunately it looks like there is a problem with typing some of the values to determine if the value is a date, time or datetime. I will report this problem to the developer. In the meantime, you will need to recall the generated DATA step code assuming you are using PROC IMPORT in interactive mode. To recall the generated DATA step code, you will need to make certain you have the EDITOR window active and then do a RUN-RECALL LAST SUBMIT after the PROC IMPORT has run. The generated DATA step will appear in the Editor Window and you can change the INFORMAT, FORMAT and INPUT statement for the 2 variables, VSBT and GNDRCODE, so they are read in as character. Then you will resubmit the generated DATA step code to receive expected results. Since I still have SAS 8.2 installed, I'm going to run my PROC IMPORT steps in 8.2 rather than introduce the manual step into the middle of an automated series of steps. My data contains codes for gender (2201 for Male and 2202 for Female). When I read those values from a .csv file into SAS using PROC IMPORT, SAS creates a numeric variable (fine) but uses a datetime. format and the anydtdtm40. informat. , creating raw values of 1956614400 and 1959292800.
From: "Data _null_;" on 1 Oct 2009 17:39 On 10/1/09, Deborah Testa <dtesta(a)sevenofninesystems.com> wrote: > My years-old PROC IMPORT code broke in 9.2 TS2M0. There are always incompatibilities with version upgrades. They are hard to find, and like this one very annoying. We (SAS-L) have already identified a bug in PROC IMPORT with regards to LRECL on the INFILE statement. I'm not sure I would have trusted PROC IMPORT for "production" program. Did the CSV change format from run to run that made PROC IMPORT more convenient? If you only need to know variable order from row 1 and type and other attributes are static you can write a two data step program that simulates what PROC IMPORT is doing for now. This program would be less likely to out smart itself. > The algorithm to determine if a value is a date, datetime or time was > changed in SAS 9.2. Unfortunately it looks like there is a problem with > typing some of the values to determine if the value is a date, time or > datetime. I will report this problem to the developer. In the > meantime, you will need to recall the generated DATA step code assuming > you are using PROC IMPORT in interactive mode. To recall the generated > DATA step code, you will need to make certain you have the EDITOR window > active and then do a RUN-RECALL LAST SUBMIT after the PROC IMPORT has > run. The generated DATA step will appear in the Editor Window and you > can change the INFORMAT, FORMAT and INPUT statement for the 2 variables, > VSBT and GNDRCODE, so they are read in as character. Then you will > resubmit the generated DATA step code to receive expected results. This could be automated with a PROC PRINTTO LOG= and a fiddly data step. Might be fun to try that. > Since I still have SAS 8.2 installed, I'm going to run my PROC IMPORT > steps in 8.2 rather than introduce the manual step into the middle of an > automated series of steps. > > > > My data contains codes for gender (2201 for Male and 2202 for Female). > When I read those values from a .csv file into SAS using PROC IMPORT, > SAS creates a numeric variable (fine) but uses a datetime. format and > the anydtdtm40. informat. , creating raw values of 1956614400 and > 1959292800. >
From: Arthur Tabachneck on 1 Oct 2009 17:46 Deborah, If you are indicating that the new proc import will treat any or even some 4-digit numbers as being datetime variables, I would hope that SAS kept staff overtime to correct the situation. Can any birdies confirm? Art -------- On Thu, 1 Oct 2009 17:26:51 +0000, Deborah Testa <dtesta(a)SEVENOFNINESYSTEMS.COM> wrote: >FYI: > > > >My years-old PROC IMPORT code broke in 9.2 TS2M0. Here's an explanation >and a suggested work-around from SAS tech support: > > > >The algorithm to determine if a value is a date, datetime or time was >changed in SAS 9.2. Unfortunately it looks like there is a problem with >typing some of the values to determine if the value is a date, time or >datetime. I will report this problem to the developer. In the >meantime, you will need to recall the generated DATA step code assuming >you are using PROC IMPORT in interactive mode. To recall the generated >DATA step code, you will need to make certain you have the EDITOR window >active and then do a RUN-RECALL LAST SUBMIT after the PROC IMPORT has >run. The generated DATA step will appear in the Editor Window and you >can change the INFORMAT, FORMAT and INPUT statement for the 2 variables, >VSBT and GNDRCODE, so they are read in as character. Then you will >resubmit the generated DATA step code to receive expected results. > > > >Since I still have SAS 8.2 installed, I'm going to run my PROC IMPORT >steps in 8.2 rather than introduce the manual step into the middle of an >automated series of steps. > > > >My data contains codes for gender (2201 for Male and 2202 for Female). >When I read those values from a .csv file into SAS using PROC IMPORT, >SAS creates a numeric variable (fine) but uses a datetime. format and >the anydtdtm40. informat. , creating raw values of 1956614400 and >1959292800.
From: Deborah Testa on 1 Oct 2009 18:26 Art, I vote for overtime! It turns out that the 8.2 version of PROC IMPORT is missing an option (GUESSINGROWS) that is important to the accuracy of the resulting data set. So I still don't have a good answer except to uninstall 9.2 and reinstall 9.1. I could write hard-coded data steps, but those will break as soon as the vendor decides to change the structure of the file one week -- and I have every reason to believe they will do that and not tell me. That's why I live with the uncertainty of PROC IMPORT, despite data _null_'s reminder that it isn't trustworthy. I'm ruing the upgrade to 9.2 right now. "Arthur Tabachneck" <art297(a)NETSCAPE.NET> wrote in message news:200910012146.n91KEIJN017810(a)malibu.cc.uga.edu: > Deborah, > > If you are indicating that the new proc import will treat any or even some > 4-digit numbers as being datetime variables, I would hope that SAS kept > staff overtime to correct the situation. > > Can any birdies confirm? > > Art > -------- > On Thu, 1 Oct 2009 17:26:51 +0000, Deborah Testa > <dtesta(a)SEVENOFNINESYSTEMS.COM> wrote: > > >FYI: > > > > > > > >My years-old PROC IMPORT code broke in 9.2 TS2M0. Here's an explanation > >and a suggested work-around from SAS tech support: > > > > > > > >The algorithm to determine if a value is a date, datetime or time was > >changed in SAS 9.2. Unfortunately it looks like there is a problem with > >typing some of the values to determine if the value is a date, time or > >datetime. I will report this problem to the developer. In the > >meantime, you will need to recall the generated DATA step code assuming > >you are using PROC IMPORT in interactive mode. To recall the generated > >DATA step code, you will need to make certain you have the EDITOR window > >active and then do a RUN-RECALL LAST SUBMIT after the PROC IMPORT has > >run. The generated DATA step will appear in the Editor Window and you > >can change the INFORMAT, FORMAT and INPUT statement for the 2 variables, > >VSBT and GNDRCODE, so they are read in as character. Then you will > >resubmit the generated DATA step code to receive expected results. > > > > > > > >Since I still have SAS 8.2 installed, I'm going to run my PROC IMPORT > >steps in 8.2 rather than introduce the manual step into the middle of an > >automated series of steps. > > > > > > > >My data contains codes for gender (2201 for Male and 2202 for Female). > >When I read those values from a .csv file into SAS using PROC IMPORT, > >SAS creates a numeric variable (fine) but uses a datetime. format and > >the anydtdtm40. informat. , creating raw values of 1956614400 and > >1959292800.
From: NordlDJ on 1 Oct 2009 19:19 > -----Original Message----- > From: SAS(r) Discussion [mailto:SAS-L(a)LISTSERV.UGA.EDU] On Behalf Of > Arthur Tabachneck > Sent: Thursday, October 01, 2009 2:47 PM > To: SAS-L(a)LISTSERV.UGA.EDU > Subject: Re: PROC IMPORT Bug in 9.2 TS2M0 > > Deborah, > > If you are indicating that the new proc import will treat any or even some > 4-digit numbers as being datetime variables, I would hope that SAS kept > staff overtime to correct the situation. > > Can any birdies confirm? > > Art > -------- > On Thu, 1 Oct 2009 17:26:51 +0000, Deborah Testa > <dtesta(a)SEVENOFNINESYSTEMS.COM> wrote: > > >FYI: > > > > > > > >My years-old PROC IMPORT code broke in 9.2 TS2M0. Here's an explanation > >and a suggested work-around from SAS tech support: > > > > > > > >The algorithm to determine if a value is a date, datetime or time was > >changed in SAS 9.2. Unfortunately it looks like there is a problem with > >typing some of the values to determine if the value is a date, time or > >datetime. I will report this problem to the developer. In the > >meantime, you will need to recall the generated DATA step code assuming > >you are using PROC IMPORT in interactive mode. To recall the generated > >DATA step code, you will need to make certain you have the EDITOR window > >active and then do a RUN-RECALL LAST SUBMIT after the PROC IMPORT has > >run. The generated DATA step will appear in the Editor Window and you > >can change the INFORMAT, FORMAT and INPUT statement for the 2 variables, > >VSBT and GNDRCODE, so they are read in as character. Then you will > >resubmit the generated DATA step code to receive expected results. > > > > > > > >Since I still have SAS 8.2 installed, I'm going to run my PROC IMPORT > >steps in 8.2 rather than introduce the manual step into the middle of an > >automated series of steps. > > > > > > > >My data contains codes for gender (2201 for Male and 2202 for Female). > >When I read those values from a .csv file into SAS using PROC IMPORT, > >SAS creates a numeric variable (fine) but uses a datetime. format and > >the anydtdtm40. informat. , creating raw values of 1956614400 and > >1959292800. Art, I just put the following data in a file called, test_import.csv gender, g2 '2201',1 '2202',2 '2201',1 '2202',2 '2201',1 '2201',1 '2201',1 '2202',2 '2201',1 '2202',2 And then used proc import to read the file. Here is the log: 260 /********************************************************************** 261 * PRODUCT: SAS 262 * VERSION: 9.2 263 * CREATOR: External File Interface 264 * DATE: 30SEP09 265 * DESC: Generated SAS Datastep Code 266 * TEMPLATE SOURCE: (None Specified.) 267 ***********************************************************************/ 268 data WORK.TEST_IMPORT ; 269 %let _EFIERR_ = 0; /* set the ERROR detection macro variable */ 270 infile 'C:\temp\test_import.csv' delimiter = ',' MISSOVER DSD lrecl=32767 firstobs=2 ; 271 informat gender anydtdtm40. ; 272 informat _g2 best32. ; 273 format gender datetime. ; 274 format _g2 best12. ; 275 input 276 gender 277 _g2 278 ; 279 if _ERROR_ then call symputx('_EFIERR_',1); /* set ERROR detection macro variable */ 280 run; NOTE: The infile 'C:\temp\test_import.csv' is: Filename=C:\temp\test_import.csv, RECFM=V,LRECL=32767,File Size (bytes)=112, Last Modified=01Oct2009:15:30:27, Create Time=01Oct2009:14:57:05 NOTE: 10 records were read from the infile 'C:\temp\test_import.csv'. The minimum record length was 8. The maximum record length was 8. NOTE: The data set WORK.TEST_IMPORT has 10 observations and 2 variables. NOTE: DATA statement used (Total process time): real time 0.01 seconds user cpu time 0.00 seconds system cpu time 0.00 seconds Memory 258k OS Memory 18036k Timestamp 10/1/2009 4:06:18 PM 10 rows created in WORK.TEST_IMPORT from C:\temp\test_import.csv. The result is just as Deborah described. But if the gender values are not quoted, then the data is read "correctly" in SAS 9.2. SAS 9.1.3 reads the file just fine either way. So it looks like IMPORT needs a little fine tuning. In addition, you might notice that I inadvertently had a space before the variable name g2 in the first line, and SAS translated it to an underscore. I don't know if that happened in version 8, but it does in 9.1.3 and 9.2. Dan Daniel J. Nordlund Washington State Department of Social and Health Services Planning, Performance, and Accountability Research and Data Analysis Division Olympia, WA 98504-5204
|
Next
|
Last
Pages: 1 2 Prev: ODS tagsets.excelxp: What is possible and what not? Next: Rand () function in SAS |