Just leaving so quick thought, can you not just modify the first the datastep to read the data filename exTemp1 temp; data _null_; infile 'C:\Users\esi15573\Documents\BOLDLF\D1C21D.tab' firstobs=2 dsd missover;      input     VAR1 $                   VAR2 $... run; You have far more control over the import that way than using proc import.  Do a search here as there are loads of examples of importing delimited files. ... View more

You could do a proc sort with nodupkey.  Or alternatively use: proc sql;      create table WANT as      select     count(1)      from       HAVE      where     PHONENUMS is null; quit; As for freq, I don't use it so don't know. ... View more

Does this directory exist on your (where SAS is located) machine? G:\Risk\Portefølje\Eirik W\Excel_output\ The error is saying that it cannot find that path, or that you don't have write permission to that area to create the file. ... View more

Yep, just modify as: data want (drop=lsta lstb lstnum);   set have;   attrib result format=best.;   retain lsta lstb lstnum;   if _n_=1 or lsta ne cata or lstb ne catb then do;     lsta=cata;     lstb=catb;     lstnum=numbers;     result=numbers;   end;   else do;     if numbers=. then result=lstnum;      else result=lstnum * numbers;     lstnum=result;   end; run; ... View more

Could use retain: data have (drop=lsta lstb lstnum);   attrib CatA catB format=$1. Numbers format=best.;   infile cards;   input cata $ catb $ numbers; cards; A B 2 A B 3 A B 3 A B 4 B B 2 B B 3 B A 2 ; run; data want;   set have;   attrib result format=best.;   retain lsta lstb lstnum;   if _n_=1 or lsta ne cata or lstb ne catb then do;     lsta=cata;     lstb=catb;     lstnum=numbers;     result=numbers;   end;   else do;     result=lstnum * numbers;     lstnum=result;   end; run; ... View more

Just to pop my 2p's worth in, I agree with both arguments here.  Its not the DBMS developers who were being lazy, you should know what data you are dealing explicitly inside out, therefore being strict about specifying variable names shouldn't be a problem, Toad for instance has an object inspector where you can drag from a contents directly into code, so saving the typing (and the fact that SAS doesn't have this is a real annoyance).  The select * syntax for instance, whilst we are all guilty of using it, is the lazy approach, first you are selecting everything even though you may not necessarily need it, and within say  macro's could lead to some interesting outcomes. I also agree that SQL lacking the lists is rather a nuisance however this is down to the concept behind the languages.  SQL works on normalized tables, and hence there's really no need to consider long lists of variables as these would be rows. For my side, I program backwards from a spec, so the spec would be the main item to build, then from that you would order your select, fix lengths etc. then decide where that data came from etc. An example: In study A I have four columns: Parameter     result1-result3 (these being lower, upper, mean) I write a bit of code  ... select * from ... and process then output result3 to mean. In study B I have the same thing, but they have cunningly moved mean between lower and upper: I copy my code over and get and incorrect result.  The same thing, but explicitly stating variables would work in both instances: Paramter lower mean upper: ... select parameter,mean from ... (ok, not the best example). ... View more