UPDATE FYI: I contacted SI and they have determined that there is a bug (at least in SAS 9.1.3). They expect it to be fixed in the "next version".

I've narrowed it down and simplified things from my original post. The problem has nothing to do with compression or encryption.

Run the code below, using the LABEL= option. The SQL step takes almost as long as the first step (just to add a label). Also, the 'Date Modified' and 'Date Created' time stamps of the data set will be *identical*. This indicates that the entire data set is being re-created by ALTER TABLE. But it should not be. This is the bug. Same thing happens if the option is PWREQ=YES or PWREQ=NO. There may be other data set options that cause this as well. If the data set is p/w protected, there is no problem with ALTER= (alone) however.

Next, remove any data set option in ALTER TABLE and run both steps again. The SQL step runs very quickly. Also, the 'Date Created' *remains unchanged* and only the 'Date Modified' is changed during ALTER TABLE. This indicates that the data set is being altered properly and not being entirely re-created.

DATA work.test; LENGTH a1-a5 $20; DO i = 1 TO 10000000; a1 = "1"; a2 = "2"; a3 = "3"; a4 = "4"; a5 = "5"; OUTPUT; END; RUN;

PROC SQL; ALTER TABLE work.test/*(LABEL='AAA')*/ ADD CONSTRAINT NOT_NULL_A1 NOT NULL (a1); QUIT;