BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
mramzy89
Fluorite | Level 6

Entered my data and got the wrong format, what I do wrong?

 

data have;
informat Person_ID best. Date mmddyy10. Reward_ID best. Name $char15. Payment best.;
format Date mmddyy10. ;
input Person_ID Date Reward_ID Name Payment;
datalines;
1 12/20/17 0 Barry Shields Credit
1 9/30/18 135 Barry Shields Gift Card
2 1/5/16 168 Greg Norman Check
3 11/4/20 96 Mary Crazy Cash
3 11/4/20 121 Mary Crazy Cash
3 1/25/19 365 Mary Crazy Credit
;
proc print data=have;run;

 

Myresults.png

1 ACCEPTED SOLUTION

Accepted Solutions
ballardw
Super User

My suggestion would be not not not read names into a single field. If you are going to do much in the way of creating data such as this manually then perhaps creating Delimited data, a special character to separate values is more flexible in the long run as if you end up with multiple fields that might need an embedded space, as in from your example possibly the name of Store that the reward is used or earned at, then trying to mix fixed column input and some of the other input types can be tricky. This is specified on the INFILE statement.

data have;
   infile datalines dlm=',' dsd truncover;
   informat Person_ID best. Date mmddyy10. Reward_ID best. FirstName Lastname $char15. Payment $6.;
   format Date mmddyy10. ;
   input Person_ID Date Reward_ID FirstName Lastname Payment;
datalines;
1,12/20/17,0,Barry,Shields,Credit
1,9/30/18,135,Barry,Shields,Gift Card
2,1/5/16,168,Greg,Norman,Check
3,11/4/20,96,Mary,Crazy,Cash
3,11/4/20,121,Mary,Crazy,Cash
3,1/25/19,365,Mary,Crazy,Credit
4,04/04/2020,1234,Jon,Von Neuman,Cash
5,,5555,Frodo,Baggins,Cash ;

Note the added record. And the correction of the Payment variable type to credit so it will accept "Cash" or "Credit" as values.

 

One reason not to place names in a single field, typical reporting on names often is done on alphabetical by last name then first name.

Second names with embedded spaces get hard to distinguish which is first or last programmatically when needed. If you separate them at entry then there is never a question.

Third if someone screws up a minor bit in along file and you end up with Lastname="Mary" and Firstname="Crazy" it isn't hard to correct.

 

I have dealt with data from a single name format like you suggested and spent most of week getting it into a proper First, Last, Middle name structure for comparison with other data. You may end up at some time dealing with "names" that you cannot tell culturally for "first" or "last" if all in one field and that can cause lots of additional work later.

 

The DSD option also allows you to indicate a missing value by placing two commas adjacent.

Plus if you later need to add a field, like company name, that might contain a comma you could enter it as ,"Acme Boot Company, Inc." and the , is read as data when placed between quotes.

View solution in original post

4 REPLIES 4
PeterClemmensen
Tourmaline | Level 20

Try this

 

data have;
input Person_ID Date :mmddyy10. Reward_ID Name $ 16 - 28 Payment $ 30 - 38;
format Date mmddyy10. ;
datalines;
1 12/20/17 0   Barry Shields Credit    
1 9/30/18  135 Barry Shields Gift Card 
2 1/5/16   168 Greg Norman   Check     
3 11/4/20  96  Mary Crazy    Cash      
3 11/4/20  121 Mary Crazy    Cash      
3 1/25/19  365 Mary Crazy    Credit    
;
mramzy89
Fluorite | Level 6

Thanks for your help. I kind of remembered this technique. the problem with the technique though is counting the characters to get them in the sas column correctly, in the event that I added another name. I might have to change character range and that is a hassle.

ballardw
Super User

My suggestion would be not not not read names into a single field. If you are going to do much in the way of creating data such as this manually then perhaps creating Delimited data, a special character to separate values is more flexible in the long run as if you end up with multiple fields that might need an embedded space, as in from your example possibly the name of Store that the reward is used or earned at, then trying to mix fixed column input and some of the other input types can be tricky. This is specified on the INFILE statement.

data have;
   infile datalines dlm=',' dsd truncover;
   informat Person_ID best. Date mmddyy10. Reward_ID best. FirstName Lastname $char15. Payment $6.;
   format Date mmddyy10. ;
   input Person_ID Date Reward_ID FirstName Lastname Payment;
datalines;
1,12/20/17,0,Barry,Shields,Credit
1,9/30/18,135,Barry,Shields,Gift Card
2,1/5/16,168,Greg,Norman,Check
3,11/4/20,96,Mary,Crazy,Cash
3,11/4/20,121,Mary,Crazy,Cash
3,1/25/19,365,Mary,Crazy,Credit
4,04/04/2020,1234,Jon,Von Neuman,Cash
5,,5555,Frodo,Baggins,Cash ;

Note the added record. And the correction of the Payment variable type to credit so it will accept "Cash" or "Credit" as values.

 

One reason not to place names in a single field, typical reporting on names often is done on alphabetical by last name then first name.

Second names with embedded spaces get hard to distinguish which is first or last programmatically when needed. If you separate them at entry then there is never a question.

Third if someone screws up a minor bit in along file and you end up with Lastname="Mary" and Firstname="Crazy" it isn't hard to correct.

 

I have dealt with data from a single name format like you suggested and spent most of week getting it into a proper First, Last, Middle name structure for comparison with other data. You may end up at some time dealing with "names" that you cannot tell culturally for "first" or "last" if all in one field and that can cause lots of additional work later.

 

The DSD option also allows you to indicate a missing value by placing two commas adjacent.

Plus if you later need to add a field, like company name, that might contain a comma you could enter it as ,"Acme Boot Company, Inc." and the , is read as data when placed between quotes.

mramzy89
Fluorite | Level 6

Thanks for your recommendations regarding the names but yes writing data with the comma delimeter made it easy.

sas-innovate-2024.png

Available on demand!

Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.

 

Register now!

Mastering the WHERE Clause in PROC SQL

SAS' Charu Shankar shares her PROC SQL expertise by showing you how to master the WHERE clause using real winter weather data.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 4 replies
  • 1327 views
  • 0 likes
  • 3 in conversation