Many users here don't want to download Excel files because of virus potential, others have such things blocked by security software. Also if you give us Excel we have to create a SAS data set and due to the non-existent constraints on Excel data cells the result we end up with may not have variables of the same type (numeric or character) and even values.   You also do not provide any STARTING data at all. As a minimum we would need a working data step that creates a TEST data set that will yield a similar behavior to your problem. The data step code should be pasted into a text or code box, opened on the forum by clicking on either the </> or "running man" icon above the main message window. These boxes will prevent the forum software from reformatting code such as by removing indentation if any was used and has been known to introduce artifacts into code so that it will not run as pasted.   Another advantage to the data step is that we can see the names and properties of variables without even running code. Sometimes that is sufficient to answer some questions.   Something else that would be helpful would be to describe what you want help with. Is it only the assignment of the visit number as implied by your subject is there something involving AVAL because you mention "worst Aval" but do not define that anywhere in the problem. And if that is in the example output you show it isn't labeled so we can't tell.   At which step is your i_need supposed to generated? Since your code doesn't mention that name for a data set the step(s) in question are a bit obtuse. Also, the "logic" throws out a lot of apparent time intervals but not a clear explanation of what the intervals are used for.   It may not hurt to define what "week" means to you as SAS has some function that are more direct interval calculations. Though I suspect that anything using a changing length and thinking of it as "week" is problematic along those lines.   Without starting data I can see a couple of places that could result in unexpected results. The most obvious would be having more than one missing ADY value sequentially or identical values of ADY, presumably across whatever PARAMCD is. Which could be occurring on the same date but at different times of day. Another is where you take the full TEST1 data set and then append records using SET statement. I would almost think that a MERGE on subjid and avistn (or other identifying variables) would make more sense if the purpose is just to add one number. There are also places that you assign missing to the new_avist and new_avistn variables. Missing is smaller than all other values so the order of processing in the SQL portion of that macro may not be as expected.   ... View more

In this case if the suggestion is to run Proc Contents then I would say the system is failing way earlier. Such as when reading the data into SAS. If you control the read, such as with DATA step code instead of Import then the Proc Contents should be moot. Or if linking to an external data system they are changing specs on the source data and the read process is not checking early enough.  Symptom in the log: NOTE: The data set WORK.FINAL has 0 observations. Root cause: A WHERE condition is too restrictive or mismatched in data type. where transaction_date = '01APR2026'; But transaction_date is a SAS date (numeric), not a character value. How a pro fixes it: where transaction_date = '01APR2026'd; Pro lesson: :white_heavy_check_mark: Always confirm variable types using PROC CONTENTS :white_heavy_check_mark: Empty outputs are often logic issues, not syntax issues I spent 10 years working on a government data project where we could not get the contracts people concerned with the data required to report on the activities to be specified as part of the contracts. As a result I had to deal with data "sources" that changed content, layout, file type and access methods as often as monthly. The report pieces had to be rewritten to deal with the data changes frequently because the data was such different.  I especially enjoyed dealing with the files that would have columns change from date to currency or vice versa part way through the file for single columns (really really hate dealing with spreadsheet data sources). ... View more

Don't be surprised if you end up having to get your IT staff involved and talking with a SAS tech representative. Some of the policies that organizations have imposed on users may prevent writing to the locations that the SAS install requires.  ... View more

If you have an SPSS install and export the data to SAS with the correct options it should create a SAS program with Proc Format statements.  Then you may be able to modify the format to use the special characters by use of unicode. You might still have issues with seeing the results properly depending on the SAS encoding if that doesn't support the unicode characters.   If you have to rely on the SAS import for SAV files then I suspect the only option will be to write data step code to modify the values to something your system will handle and possibly write a custom formats get the special characters to display using an acceptable font and/or unicode. Which may be long task if there are many of these special values.   Without knowing the required system encoding and font used can't provide anything better at this time.   ... View more

"Stopped being recognized" implies that the key strokes had been recognized before. But that "before" often means that something in your system changed. It may help to describe any recent changes in your system. Have there been any updates to software recently? And since ctrl-F and H are system keys in many respects system changes count. Or did you change something and didn't change it back? For example in the SAS display manager the ctrl-F and H brings up a dialog box that has some options such as Find in Code and comments, Find in code only or Find in Comments only. If you set one of those options they persist until changed. So if have set Find in Comments then the find won't find anything in the code section. Or if you clicked on the Match Whole Word or Case options you might not be finding as expected.  And the Replace won't work if nothing is found.   I've had keyboard errors such that the proper codes aren't sent to the computer and keyboard models that either require additional key settings or strokes to send standard function key codes.     Also as @ChrisHemedinger mentioned which environment.   ... View more

@NewUsrStat wrote: Thank you very much for your help. Unfortunately the code that refers to the array does not work. But, anyway, how it become if the value of the variable is repeated identical? What does "array does not work"?  If code throws an error then provide the log with the code and all the messages. Copy the text from the log then on the forum open a text box in a message using the </> icon above the message window and paste the code.   If the result is not as expected then provide the data used in the form of a working data step and then provide more detail as to the expected result for the example data.   I am afraid that a generic "does not work" is very unhelpful in diagnosing problems. ... View more

To use a macro variable such as &outpath, the & meaning the following is the name of a macro variable, then prior to the use of the variable you should have a statement similar to : %let outpath = d:\thisfolder; (for Windows) or %let outpuath= drivemountpointname/thisfolder;  Or possibly other code that does similar with data step and the CALL SYMPUTX option or Proc SQL code with and INTO instruction to write results into a variable named Outpath.   In the case of canned programs from a SAS course this is usually done in either a set  up program or there is an instruction to uncomment a bit of code and replace some example text with the path on your system. I would look in your instructions for a %let statement to modify.   ... View more

Dealing with such overlapping intervals you may have to provide some additional rules. Such as this case where a second starts within another interval but extends past the discharge of a previous interval. ID AdmitDate DischargeDate 1 1/1/2025 2/4/2025 1 1/17/2025 3/23/2025 What would you do in this case?   If, and this is a pretty big if in some situations you actually do only want the "initial", defined as the earliest admit date then on approach might be to sort but ID and Admit date. Then with the sorted data you might be able to use something like this: Data want; set datasorted; by id admitdate; if first.id; run; If the data is sorted by id and admitdate, assumes admitdate is a SAS date value numeric and hopefully with a date type format applied. The BY statement creates automatic variables for each variable that are referenced as First.variablename or Last.variable which are numeric 1/0 valued variables that SAS will treat as true/false to test if a value is the first or last of a given by group. So the IF First.ID, a subsetting IF, keeps only the observations with the first occurrence of an ID value.   However the above likely will not work if there are multiple admit sets, such as ID 1 having another admit 05/05/2025.   So a more complete description of likely scenarios and a few more rules are needed. ... View more

@palolix wrote: Thank you very much for your suggestion.   I changed the variable names as you suggested (FruitWt_Day0 etc) and then modified the code to this but I still get the same errors for the array   Changing the name of the variable does not change the variable type. So if you have a mix of character and numeric values as your error messages says then the change has absolutely no effect. The bit about naming similar variables this way is more helpful starting with reading the data initially and making sure that all the variables of the same group are of the same time. Then analysis or manipulation goes quicker. ... View more

If you provide some example data in the form of a working data set you might get working code. One way would be to use Proc Format to create a custom format for the county code variable and apply the format to the code variable in proc freq. Here is a brief example: Proc format; value county_code 1 = 'A' 2 = 'B' 5 = 'C' 4 = 'D' 3 = 'E' 6 = 'F' ; run; data example; input County_code yes_no $; datalines; 1 Yes 1 No 3 Yes 5 No 5 Yes 2 Yes 6 No ; Proc freq data=example; table county_code*yes_no; format county_code county_code. ; run; I didn't bother to put the county name variable in the example data set because the code value is all that is needed.   The format name does not have to be the same as the variable it just makes it easier to keep track of. Note the use of the period at the end of the format name in the format statement. That is how SAS knows that is the format and not a variable.   Formats are a very powerful tool because additional formats can be used with the same data set and variable to get different analysis. For example with something like a county code variable I could create a format that assigns the codes to something like geographic management regions, my state has 6 or 7 depending on whether you are working with Public Health Districts or Education regions for example. Or by some other characteristic such as population size group or density, mean income or just about anything. Then the only change to an analysis is using the format. Proc format can use a data set with codes and such descriptions as well to avoid writing a lot of code such as for Texas which has over 250 counties. If the codes are character and not numeric the format name in the proc format code needs be prefaced with a $ and when used in a format statement. This is needed because you could have separate formats for a numeric and character values.               ... View more

I would suggest using one of the SAS supplied data sets such as SASHELP.CLASS or SASHELP.CARS with Proc Gplot using similar options that demonstrates the same behavior.  Then show us the complete code from that example.  That way things like the incomplete AXIS1 and LEGEND1 definitions, missing a semicolons, would be addressed and removed as possible sources of a problem. Also it very often more useful to see the LOG with the notes and any warnings or errors involved with the code. For example, with your current code shown with the Axis and Legend statements incomplete then possibly the current code did not replace a previous file because Proc Gplot would not actually run with the shown code. The LOG would clear that up. Copy the text from the log, on the forum open a text box using the </> icon above the message window and paste the copied text. The text box preserved formatting that would be removed in the main message window. Here is an example LOG based on your posted code modified to use a set that exists on my system and a plot statement. Note the syntax errors thrown by the incomplete statements. 21 AXIS1 LABEL = ("test label") 22 LEGEND1 LABEL=("TEST LABEL") ------- 22 202 23 SHAPE=BAR(10pt,10pt) ----- 22 76 ERROR 22-322: Syntax error, expecting one of the following: ;, ',', COLOR, INTERVAL, LABEL, LENGTH, LOGBASE, LOGSTYLE, MAJOR, MINOR, NOBRACKETS, NOPLANE, NOSTAGGER, OFFSET, ORDER, ORIGIN, REF, REFLABEL, SPLIT, STAGGER, STYLE, VALUE, WIDTH. ERROR 202-322: The option or parameter is not recognized and will be ignored. ERROR 76-322: Syntax error, statement will be ignored. 24 PROC GPLOT DATA=sashelp.class ; 25 TITLE1 "test title"; 26 plot height*weight ---- 180 ERROR 180-322: Statement is not valid or it is used out of proper order. 27 FRAME 28 LEGEND=LEGEND1 29 HAXIS=AXIS1; 30 RUN ; 31 quit;   Is the image you show as created by SAS or after import into WPS? From your description it seems like you had a process working that changed when your client changed their software. Or did your data change making the graph appear different in the SAS created file?       You may also want to run Proc GDEVICE to get a listing of the current settings of your GIF device driver. It might be that something modified that driver. Code using the default location of the SAS/Graph devices: Proc gdevice nofs catalog= sashelp.devices ; list gif; run; and likely result: GDEVICE procedure Listing from SASHELP.DEVICES - Entry GIF Orig Driver: GIF Module: SASGDDMX Model: 19999 Description: GIF Universal Printer Type: PRINTER *** Institute-supplied *** Lrows: 43 Xmax: 8.333 IN Hsize: 0.000 IN Xpixels: 800 Lcols: 88 Ymax: 6.250 IN Vsize: 0.000 IN Ypixels: 600 Prows: 0 Horigin: 0.000 IN Pcols: 0 Vorigin: 0.000 IN Aspect: 0.000 Rotate: Driver query: Y Queued messages: N Paperfeed: 0.000 IN OPTIONS Erase: Autofeed: Chartype: 0 Swap: Cell: Maxcolors:17E6 Autocopy: Characters: Repaint: 0 Handshake: Circlearc: Gcopies: 0 Dash: Gsize: 0 Prompt - startup: Fill: Speed: 0 end graph: Piefill: Fillinc: 0 mount pen: Polyfill: Maxpoly: 3000 chg paper: Symbol: Lfactor: 0 Pensort: N Promptchars: '000A010D05000000'X Rectfill: '8000800000000000'X Dashline: 'FFFFFFFFFFFC0000'X Devopts: 'DDC3A0C809E823C8'X UCC: '0021010A000004010A0000040000000000010001'X Cback: WHITE Color list: BLACK RED GREEN BLUE CYAN MAGENTA GRAY PINK ORANGE BROWN YELLOW BISQUE CORAL LIME MAROON DARKGRAY DEEPPINK DIMGRAY NAVY OLIVE PERU PLUM GOLD THISTLE HOTPINK INDIGO KHAKI LAVENDER PURPLE SIENNA SILVER SKYBLUE TAN TEAL TOMATO VIOLET WHEAT CHARTYPE RECORDS Chartype Rows Cols Font Name Scalable 0 1 1 <MTmonospace> Y FILE INFORMATION Gaccess: Gsfname: Gsfmode: REPLACE Gsflen: 0 Trantab: Devmap: Devtype: GTERM Gprotocol: Fileclose: DRIVERTERM Hostspec: HOST INFORMATION It has been a long time since I played with the Graph devices but this may provide some help.   ... View more

You would need one or more procedures that write output such as Proc Print, Proc Report, a data step with the correct options, a modeling proc, something. Then there would have to be an ODS EXCEL CLOSE; after the procedures so SAS knows when you are done writing to the file. ... View more

I am going to throw in a style choice that your or your office is made that is making you write more code than is needed for array processing.  By placing the interval measures of 0, 3, 7 (or others) in the middle of the variable name you keep yourself from using the variable list features of SAS. If the variables were named for example FruitWt_Day0, FruitWt_Day3 and Fruitwt_Day7 you could write the ARRAY statement as: Array _FruitWt (*) Fruitwt:  ; The colon immediately after FruitWt tells SAS to use all the variables whose names start with Fruitwt. Or if you have other such variables then use Fruitwt_Day:  to get only those suffixed with Day.   Have you actually run Proc Contents yet? Or opened the data set and examined ALL the variables used in those array statements? Or actually closely read the LOG? That particular error will only appear immediately after the statement causing the error. Se this example from my log. 187 data junk; 188 set sashelp.class; 189 Array x (*) Name sex height; ERROR: All variables in array list must be the same type, i.e., all numeric or character. 190 array y (*) age height weight; 191 run; So be reading the log I can tell that one of the variables referenced on the Array X statement has a problem. So it is one of Name Sex or Height. The first two are character and the third is numeric. As shown by this from Proc Contents: Alphabetic List of Variables and Attributes # Variable Type Len 3 Age Num 8 4 Height Num 8 1 Name Char 8 2 Sex Char 1 5 Weight Num 8   ... View more

I agree with @Tom that several details are missing.   Your bit here: @NewUsrStat wrote: ... Moreover the format the variables will take is exactly their value like for example proc format ... "Chemotherapy" = "Chemotherapy"  "Transplant" = "Transplant", ....    If you have a data set of values that you expect to encounter you can use that data to make a CNTLIN data set for Proc format. Here is an example using the SASHELP.CLASS data set that you should have. /* select all the males from the data set and create a format that will show that text as the label and "Other" for the females */ data example_cntlin; /* the END = option is to allow conditional creation of the OTHER statement options as the last entry of the format*/ set sashelp.class (where=(sex='M')) end=lastone; /* key variables that a Proc Format CNTLIN requires are Fmtname start (end if there is range of values) label type, C for character here, and since we want to use the OTHER option the HLO variable which may contain other things */ fmtname='F_to_other'; start=name; label=name; type='C'; output; if lastone then do; /* that is a capital O not a zero*/ hlo='O'; /* special text for the Start/end values with Other*/ start='**OTHER**'; label='Other'; output; end; drop name sex age height weight; run; /* use the data set to create the format*/ proc format cntlin=example_cntlin; run; /* demonstrate how to use the format created*/ proc print data=sashelp.class noobs; var name; format name $F_to_other.; run; If you have any questions about what special values in which special variables used by Proc Format for a CNTLIN data set it is pretty easy if you know the options you need. Write a very small Proc format step with the options you need be they ranges, invalues (informats) or whatever. Add on the Proc Format statement the option CNTLOUT=somedataset. The procedure will create a data set with the variables needed and the options.   Caveat: If you have multiple variables in in a single data set that you want to work with you must make sure that the final data set is sorted by the FMTNAME variable as otherwise Proc Format will create and overwrite a bunch of basically one value versions of the formats. It might be best to create one CNTLIN data set per set of values/variable for simplicity sake. Keep the sets in a permanent library. Suggest also writing the Formats to a permanent library using the LIBRARY= option and then adding that library to the FMTSEARCH  path so you don't have to recreate the formats each session.   If your clinicians are anything like the ones I worked with you may need to make sure that the spelling is consistent because a value of "Xyz" the format is looking for will not match "xyz". I often fixed that by creating custom informats that used the UPCASE option that would treat all the text as uppercase before comparing to value on the informat and assigning the proper expected values.    Something like this: Proc format; invalue $sometext (upcase) 'ABC'='Abc' 'PDQ'='Pdq' 'JACK DANIELS' = 'Jack Daniels' other=_same_; run; data example; input text $sometext.; datalines; abc abC ABc pdq somethiing else ; The CNTLOUT option would show where the UPCASE gets set in the control data set. Note the use of _SAME_ to copy any unexpected text. The CNTLIN data set would want the START value to be all uppercase.    If you have known supposedly fixed set of values, such as Clinic names, you could use the _ERROR_ option in the INVALUE to throw an error when an unexpected value gets entered into a data set so the LOG would throw invalid data messages. If you find that one of your clinicians abbreviates or misspells a value consistently you could add that to the Invalue as format has not problems taking multiple input values to the same output. I used this frequently because one of our contractors would "update" their data system so that things that had been established to report a value as M or F for female would do things such as spell the word out or add a / and the Spanish equivalent. I could modify my informats to accommodate such and keep the original correct values in our data.   I always thought Proc Format was one the hidden gems of data management as long a single variables were involved.  ... View more

@Ok6 wrote: Thanks but error persists. Best practice for this forum is to show the code and any messages from the log. Copy the text from the log starting with the code statements submitted that are having an issue through the end of all of the messages associated with the code. On the forum open a text box using the </> icon that appears above the message window and paste the copied text.   The text box is important because the software running the forum will reformat text pasted into the main message window that sometimes reduces the readability or completeness of the diagnostics that SAS often supplies.   In the case of "file doesn't exist" type messages common problems are spelling , case of text, actual location of the file such as attempting to use a local to your computer file where the server running SAS cannot see it. If you show the actual code and messages we can help better. Also, it would be better to start your own thread instead of adding to an older thread. The creator of the thread has options available such as marking an answer correct that others do not. If you do start your own thread you can post a link to this one to reference what has been done so far.  ... View more