topic proc sql order of returned data in SAS Procedures

proc sql order of returned data

gaultie — Tue, 18 Apr 2017 17:02:18 GMT

SAS discussion board

Anyone have any idea how PROC SQL orders returned data for variables which have not been explicitly ordered or if there is a way of controlling it - for example with a many to many merge. Is there a rule about the order in which variables which are not explicitly part of the merge will be ? It does not seem to necessarily be the order in which they were in the source data. We are using SAS 9.3

With proc sort there is a system option (SORTEQUALS) which forces the order of the non sorted variables to be as in the source data but is there a similar control with proc sql ?

Good practice will be to explicitly include the desired order in the proc sql but just wondering if there is a solution that does not require a change to code (other than perhaps an option). The problem has arisen as part of a move to SAS Enterprise Guide. Oddly exactly the same proc sql code returns observations in a different order (within by group) if submitted from a display manager interface compared to if submitted from Enterprise Guide. I can't reproduce with a simple dummy example.

Re: proc sql order of returned data

Tom — Tue, 18 Apr 2017 17:19:59 GMT

SQL makes no guarantee on ordering. You might be seeing the results of running on multiple threads causing a change in the order.

If you really do not have a set of keys then just order on everything. You can use PROC SORT and the _ALL_ variable list. If you did have some partial keys that you want to order on add those in front of the _ALL_ keyword.

proc sort data=have;
  by key1 key2 _all_;
run;

Re: proc sql order of returned data

ChrisBrooks — Wed, 19 Apr 2017 10:29:13 GMT

If I can echo what Tom says SQL makes no guarantee of order. In fact the SQL language was designed for relational databases and when I was taught relational database theory (many decades ago) I was told that in an RDBMS order of records should never matter.

If you're running your code against say ORACLE it's possible, as Tom says, that internally ORACLE is threading your query without you realising it.