format $DATE was not found -- possible config error?

[dpurcell99]

Hi all,

A colleague continues to receive the error below running SAS 9.3 locally. However, I can run the same code with the same data on the same type of laptop with no problem.

Is it possible that this is due to a configuration error of some sort? The reason I ask is that she inherited this computer from a former colleague, and I wonder if there is something that was initially configured for his username that has not clicked with hers. I searched through all of the config settings in Tools/Options/System, and I can't see any differences. Our IT department is no help. It just doesn't make sense to me that I can run the same code with the same input data and it works fine.

Any ideas? Thanks!

--------------------------------------

data rawdata;

86     format monthdt date9.;

87     set new;

88

89     date1 = put(reportdate, date9.);

                               ------

                               48

ERROR 48-59: The format $DATE was not found or could not be loaded.

[naveenraj]

This can happen when you don't have the format library where the SAS dataset located. Without the format library, SAS will not permit you to do anything with the data file.

try using options nofmterr; in ypur program to see if the error is still there.

[ballardw]

Likely your reportdate variable is character. So when you Put the variable SAS looks for a TEXT format (the $ part of the name). Since there is no SAS supplied $date format then it reports it can't find it.

Run Proc contents on the dataset new and see what it says about the variable reportdate.

[RW9]

Are you sure the dataset - NEW, and in particular the variable REPORTDATE is the same across the two variables.  It sounds like on your system the variable is a numeric, which you then put into a text string.  However is reportdate is a character, then it will try to find a $date format which doesn't exists.  So check the dataset matches between yours and their computers.

[dpurcell99]

Thanks for the fast replies, all. This is helping me down the path towards a solution. Although we are pulling from the same source data with the same source code, it is being read in differently for each of us. See the differences in proc contents below. Our SAS installations should theoretically have the same options. Are these kinds of defaults set somewhere, and if so, what should I look for? Thanks!

Here's the code -- this pulls the initial raw data that feeds into the code I posted earlier.

libname spssql odbc dsn='xxx' schema='sas' user=xxxx password=xxx

data hospitaldata;
    set spssql.v_rawhospitaldata;
    where questionid in (xxx,xxx,xxx);
run;

When I run proc contents on set spssql.v_rawhospitaldata on my side, I get:

When I run it on her machine, I get:

Note that there are many differences: e.g,. my first field (AnswerText) is longer than hers; my ReportDate is being read in with DATETIME26.7 while here is $27 and so on. But they are pulling from the same place with literally the same code. Which leads back to my question -- is there a place where the defualt format/input options are set in the config? Thanks!!

[jklaverstijn]

I think it is time to start doiubting your assumptions. Quote: "But they are pulling from the same place with literally the same code.". No way that would lead to different data types. You are wondering about the formats but they are less fuindamental then datatype. And when these differ there is no way the two datasets have the same origin.

It looks like all your dates were transformed to char using there associated datetime26.7 format. That would mean your code should use an INPUT() instead of a PUT(). INPUT() translates backl from char to num using an appropriate INformat (likely DATETIME26.7).

So easy fix but some questions remain as far as the lineage of your datasets is concerned. The fix may in fact be a workaround.

- Jan.

[RW9 · Accepted solution]

So the data is coming from a database.  It may not be SAS at all then, it could be the ODBC driver.  Personally I would take it up with your IT group/database admins.

[dpurcell99]

Thanks again, all. RW9, I think you're on the right track -- I just compared our ODBC drivers and they are different. So now I have more info to pursue this with our IT folks, who are generally not helpful with SAS config/database issues.

Jklaverstijn -- FWIW, I did post the code above. Here it is again below -- I just run the following on both computers, and it leads to differences in the spssql.v_rawhospitaldata pulled from the db that I can see when I run proc contents.

When I find the exact issue, I'll follow up so it will be here for future refernence. Thanks again!

libname spssql odbc dsn='xxx' schema='sas' user=xxxx password=xxx

data hospitaldata;
set spssql.v_rawhospitaldata;
where questionid in (xxx,xxx,xxx);
run;

[Reeza]

Also, verify that you have the same versions of SAS and bitness (32 vs 64). 

Also make sure that DSN set up for the database is the same. 

[dpurcell99]

It turned out to be a difference in our ODBC drivers. Thanks, everyone, for helping point me in the right direction!

[ballardw]

---

@dpurcell99 wrote:

Note that there are many differences: e.g,. my first field (AnswerText) is longer than hers; my ReportDate is being read in with DATETIME26.7 while here is $27 and so on. But they are pulling from the same place with literally the same code. Which leads back to my question -- is there a place where the defualt format/input options are set in the config? Thanks!!

---

Post the code used and likely from both machines.

My guess would be that Proc Import and Excel are involved.

NOTE: The description of your data for Reportdate, the one that is numeric with format datetime26.7, should also result in date1 = ********* when created with date1= put(reportdate, date9.) as datetime variables are numbers of seconds where date variables are numbers of days and most plausible actual values of reportdate would be so large when treated as a date that the result can't be displayed with date9. as it is trying to display a date that is way too far in the future.

[jklaverstijn]

As you may have noticed the resonses are based on assumptions and guesses as to what may cause your problem. Please provide samples of your data together with code and logs. That will no doubt make the cause of your issue very obvious. I can promise you this is not a complicated problem to solve, we just need some details to take out the guess work.

- Jan.