|Date: ||Wed, 4 Apr 2007 11:05:38 -0400|
|Reply-To: ||Lorne Klassen <lk1@ROGERS.COM>|
|Sender: ||"SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>|
|From: ||Lorne Klassen <lk1@ROGERS.COM>|
|Subject: ||Re: Encryption, compression and ALTER TABLE|
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=
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
LENGTH a1-a5 $20;
DO i = 1 TO 10000000;
a1 = "1";
a2 = "2";
a3 = "3";
a4 = "4";
a5 = "5";
ALTER TABLE work.test/*(LABEL='AAA')*/
NOT_NULL_A1 NOT NULL (a1);