You see "ERROR 29-185: Width Specified for format ----  is invalid" message in the log file  when you try to specify the DATE format but used an invalid width. DATE format will not result in a date if it is too long or too short. Valid values are 5-9 in SAS 9.1.X versions. If you use newer version (SAS 9.2) then you won't see this Error message in the log. ( I am assuming that this is fixed in SAS 9.2). Try using format date9. instead of date11 . if you are using SAS 9.1.x (either Windows or Unix) version. data _null_ ; date =' 23-SEP-2004'd ; put date date11. ; * T his statement gives you error in SAS 9.1.2/9.1.3 versions ; put date date9. ; run ;

• Proc SQL requires few lines of SAS code compared with datastep and or Proc steps • Frequency counting can be done in no time… which is very helpful during the QC or validation • Proc SQL can merge datasets together using different variable names unlike datastep. • Proc SQL can merge many datasets together in the same step on different variables • Proc SQL allows you to join more than two datasets together at the same time on different levels • The merge process Proc SQL join does not overlays the duplicate by-column, where the Merge    statement of the data step does. Data step vs Proc SQL •   Data step Merge – Pre sorting of the dataset by the by-variable needed before the merging process – Requires common variable names –  May need few more lines of code than Proc SQL •   PROC SQL Join process works different than the typ...

Have you ever tried to convert the default encoding to Wlatin1 (Windows SAS Session Encoding)? Let me tell you the story behind writing this post…. Today I was asked to send SAS datasets to one of the client. I transferred the SAS datasets to the client and immediately after, I got an email from the so called client saying the encoding of SAS datasets is different this time when compared with the last transfer. He said It’s causing problems in Proc compare process. Opps… bummer…. Client’s email got me little worried ... I checked the Proc contents details and saw the change in the encoding. I investigated the issue and found out that Unicode SAS with UTF-8 encoding uses 1 to 4 bytes to handle Unicode data. It is possible for the 8-bit characters to be expanded by 2 to 3 bytes when transcoding occurs, which causes the truncation error. Because of the truncation problem I was asked to change the unicoding back to WLATIN1 so that the character data present in the SAS datasets repre...

Validation checks or tools to check the compliance of SDTM data JANUS is a standard database model which is based on the CDISC’s SDTM standard. JANUS is used by the FDA to store the submitted SDTM clinical data. As a part of data definition file submission pharmaceutical companies have to submit SAS datasets in transport file ( . xpt ) format along with annotated CRF and Define.xml file. The reason being this is… to properly load the clinical data into JANUS database which is maintained by the FDA. It is very easy for FDA reviewers to review the clinical data once they load the clinical data into their JANUS database. They can even produce ad-hoc reports and perform cross-study review at the same time. FDA runs compliance checks on the data submitted to make sure the data was collected as per the SDTM standard. FDA checks the compliance of data by running the WebSDM™ developed by PhaseForward ). WebSDM™ is a SDTM compliance check validation tool performs a set of SDTM c...

HANDLING SPECIAL EMBEDDED CHARACTERS To manage and report data in DBMS that contains very long text fields is not easy. This can be frustrating if the text field has special embedded symbols such as tabs, carriage returns (‘OD’x ), line feeds (‘OA’x) and page breaks. But here is simple SAS code which takes care of those issues. The normal line end for Windows text files is a  carriage return character or a line feed character so   The syntax for taking out all carriage return ('OD'x) and line feed ('OA'x) characters is comment= Compress(comment,'0D0A'x);                              or comment= TRANWRD(comment,'0D0A'x,’’); If you just want to take out the Carriage Return, use this code: comment= TRANWRD(comment,'0D'x,''); You could also try this one too.. Comment=compress(Comment, ,"kw"); * k is for keep, w is for "write-a...

/* create sample data */ data one; input a $ b $ c $ d e; cards; a . a 1 3 . b . 2 4 a a a . 5 . . b 3 5 a a a . 6 a a a . 7 a a a 2 8 ; run; /* create a format to group missing and non-missing */ proc format; value $missfmt ' '=' missing ' other='non-missing'; value missfmt .=' missing ' other= 'non-missing' ; run; %macro lst(dsn); /** open dataset **/ %let dsid= %sysfunc (open(&dsn)); /** cnt will contain the number of variables in the dataset passed in **/ %let cnt= %sysfunc (attrn(&dsid,nvars)); %do i = 1 %to &cnt; /** create a different macro variable for each variable in dataset **/ %let x&i= %sysfunc (varname(&dsid,&i)); /** list the type of the current variable **/ %let typ&i= %sysfunc (vartype(&dsid,&i)); %end; /** close dataset **/ %let rc= %sysfunc ( close (&dsid)); %do i = 1 %to &cnt; /* loop through each variable in PROC FREQ and ...

When programming in SAS, there is almost always more than one way to accomplish a task. Beginning programmers may think that there is no difference between using the WHERE statement and the IF statement to subset your data set. Knowledgeable programmers know that depending on the situation, sometimes one statement is more appropriate than the other. For example, if your subset condition includes automatic variables or new variables created within the DATA step, then you must use the IF statement instead of the WHERE statement. This tip shows you how and when to apply the WHERE and IF statements to get correct and reliable results. It also reviews the similarities as well as the differences between these two SAS programming approaches. Detail differences in program efficiency between the two approaches will not be covered in this tip. For more details refer to  http://support.sas.com/kb/24/286.html