It depends.  What is actually in the incoming data?  If it contains 10 characters (year, month, day, with dashes in between) then it is simple: data want; input datevar yymmdd10.; format datevar yymmdd10.; datalines; 2016-09-01 ; However, if the incoming data contains quotes, the solution is a little more complex: data want; input text $quote12.; datevar = input(text, yymmdd10.); format datevar yymmdd10.; datalines; '2016-09-01' run; It takes one statement to remove the quotes, then a second statement to convert the remaining text to a date value. ... View more

Once a variable is numeric, it is always numeric.   Once a variable is character, it is always character.    This line defines the variable A as character: a = '2016-09-01'; While the next statement works and the INPUT function generates a number, SAS now has to store that number in a character variable.  So the result of the INPUT function gets converted back to character.  There should be a note on your log about numeric to character conversion taking place at that point.     ... View more

When you test for cholesterol lt 200, that comparison includes missing values. There are several ways to fix this. One possibility is checking for missing values first, then using "else" to check for lt 200. ... View more

IMO, you are ignoring some of the more important issues.   Both SQL and a MERGE are tricky if you can have multiple observations for the same ID in both sources of data.  Just because the messages you get are different doesn't mean that the step is working properly.  For the updating programs that you describe, both methods require that you be absolutely certain that the data set you are "adding" does not contain multiple observations per ID.   Deleting a data set takes virtually no time.  If you find that to be untrue, let's examine how you delete a data set.   Once you replace a data set, the original version is no longer available.  If you add observations by either method (SQL or MERGE), and you find that the result is wrong, you can't go back.  You can't "fix" the program and try again.  The original data is no longer available.  It would save a mountain of time if you would just keep the original data sets around until you are sure they won't be needed. ... View more

As others have mentioned, the problem lies with your instructions to read in the data.  While @FreelanceReinh has shown some of the many choices you have available, the simplest (yet intuitive) way to read the data would be like this: data weather_japan; input station $ 1-17 location $ 18-40; datalilnes; ... same datalines that you posted ... ; You would have to do the work of telling SAS where to find the fields you are reading.  SAS will pull the data from the columns you specify.     Also note, this style of inputting the data will left-hand justify whatever it finds so it won't matter whether LOCATION begins in column 18 or column 19.   Finally, this can't be your final data set.  There are no variables suitable for practicing the INTNX or INTCK functions ... View more

On the surface, this seems like a horrible idea. You would make your data incredibly difficult to program with, and create the situation where col3 means something different depending on which data set you are working with. Perhaps you could describe what happens next,, after the names have been changed. We might be able to suggest a less destructive path to take to your goal. ... View more

You are missing the "n" following one of the references to 'CY_Actuals' ... View more

Will AGE always be consistent, or could the same ID have two different ages? ... View more

The most important concept is, I'm sure, covered in @SASJedi 's link.  Just to isolate it, there is a difference between variables read in, vs. variables saved.  Compare:   data want; set have (keep=a b c); run; data want (keep=a b c); set have; run; The top DATA step reads in just the variables needed so the PDV contains only a, b, and c.  The bottom data step reads in all the variables, which could be hundreds of variables.  Then it saves only a few.  All variables from HAVE would be in the PDV, but only three would be written to WANT. ... View more

Probably this is a bad idea. It will complicate your life immeasurably. For example, consider a simple task like computing the mean value of a variable. Without splitting, a simple program does the trick: proc means data=raw_data; var varname; run; To calculate the same statistics from split data, you have to jump through many hoops. First, process each subset. For the mean value, calculate the Sum and N statistics. Then add those statistics across all the subsets. Finally, calculate the overall Mean from the aggregated Sum / N. This sort of process can be done for other statistics as well such as minimum value and standard deviation. However, it would be easier to learn to work with the "unsplit" data in a more efficient way. ... View more