In general i would say instead of using a single we could accomplish the same in following steps:   1. Take dump of Table A using proc sql into SAS dataset. 2. Do the same for Table B   Load the Table B onto a proc format and apply that to table A.   This should optimize the code.   Most often the slowness of a query would depends on the connection driver either ODBC/Oracle and so on.  So the throught process should ideally be to use a method to take a dump and use the other to optimize results, so i would say use the SQL code to pull the data and not join and use SAS formatting to join the data. if it helps create use proc ds2 for parallel record processing. ... View more

Hi @bochen,   Here is a simple example which shows that the first two steps can generate different results: data a; id=1; x=2; run; data b; id=1; y=1; run; data c; id=1; x=1; run; The first PROC SQL step joins A and B on A.id=B.id to the intermediate result "one obs. with id=1, x=2, y=1" (call this T) and this with C on T.id=C.id & T.x=C.x, which results in T.   The second PROC SQL step first joins B and C on B.id=C.id to the intermediate result "one obs. with id=1, x=1, y=1" (call this V) and then joins A with V on A.id=V.id & A.x=V.x, which results in a single observation with id=1, x=2, y=. (missing), because the keys do not match.   Other examples show that even if both steps create the same observations, the results can differ in the order of observations and in the order of variables. ... View more