Date: Wed, 4 Jul 2007 22:55:13 +1000
Reply-To: d@dkvj.biz
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: David Johnson <d@DKVJ.BIZ>
Subject: Re: Get Data Back
In-Reply-To: <07123CDF07D82249A6A840A789BC2EEE03B30506@sges0004.essilor.com.sg>
Content-Type: text/plain; charset="iso-8859-1"
The password is there to force people to think about what they are
replacing. If you have to type the password, then it is data you want to
protect, and if you don't include the password the table isn't replaced.
Your password can be as simple as Data LIB.FRED( AlterPW = PASSWORD);
Its intention is not prevent replacement of the table, or to make it any
more difficult to read the data (it is an alter password, not a read
password) but to put a barrier in the way of accidentally replacing a
permanent data set.
It is part of a principle called "Defence in Depth", where a series of
barriers are employed to protect something of value. In terms of a
Programmer, the depth is that you first test the code with the library
commented out so you aren't making any changes. Then you have a process
that says your data is created first to a staging area before going to your
permanent library, and finally, you stop the tables being replaced by
accidentally running code against the table since you have a password in
place. These barriers are more about your practices than any substantive
defence, but by employing the practices every time you reduce the chance
you'll make the mistake again.
Now if you want to get really paranoid about the data, then your staging and
production libraries are on different drive systems or machines, you have a
user id and password that is the only one allowed by the Operating System to
modify the tables and you never, ever, ever use that one for your day to day
programming. Of course those people who are smart administrators of Windows
platforms have an admin account and a user account and never sign on with
the admin account except when they are doing real admin work. But in the
world of Spam and crack attacks by the Morlocks of this world, such paranoia
is actually justified.
Kind regards
David
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of VORA
Mihir
Sent: Tuesday, 3 July 2007 7:53 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Get Data Back
Thanks for your valuable suggestions David. I will surely try to implement
them from now on.
However I am not very sure of the password protection method that you
mentioned. The environment that I am working is a HP- UniX machine and is a
shared environment. Keeping a password would be tough, as multiple users
connect to the datasets and developers keep changing. Managing and
maintaining the password would also be a problem and forgetting the password
could also spell catastrophe. I think I did not get your exact point. Could
you please elaborate on managing the password in a share environment and its
advantages in saving data?
Regards,
Mihir Vora
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of David
Johnson
Sent: Monday, July 02, 2007 6:59 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: Get Data Back
I see you have had a few pertinent questions already, and doubt that there
is any quick cure for this. However, I'll trot out some hoary old advice,
and some newer ideas you might not have considered, and perhaps you'll find
a way to reduce the chance of this happening again.
Backups are essential, the cost of setting them up is almost always
substantially less than the pain and cost of recovering from a major data
loss. I recognise that with really big tables, some sites cannot
effectively back up and restore large tables.
With critical reporting tables, especially large ones, I try always to have
a staging process. Some people configure this formally with Generation data
sets, which is a really good SAS centric way, but even creating your table
to a development area, validating it and swapping it into a Production area
gives you two versions of data to work with. Then you lock the Production
version so people can enquire on it but not change it.
Using the data set option (AlterPw =) is a great addition to this model
because although the password might be something obvious, you can't write a
data step to replace the table without thinking about and including the
password declaration.
When I write an update process like this, I test it first by commenting out
the library reference on the Data statement, so that the code is tested
against a work library. 6m rows is not huge, but if time is an issue the
global or data set options OBS reduce the amount of data you test. Just
make sure you restore these to MAX before uncommenting the library
reference.
I'm sorry to hear you've lost the work and regret this may not be the last
time this happens. It is an easy mistake to make, but by reviewing your
practices, and employing changed procedures in the future, you might reduce
the risk of this happening again.
Kind regards
David
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU]On Behalf Of VORA
Mihir
Sent: Monday, 2 July 2007 4:53 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Get Data Back
Hi Folks,
I have an important table and by mistake I forgot to add the set statement
while trying to modify the dataset. Is there any way I can revert back to
the original dataset?
I should have used
data abc;
Set abc;
If x = "y" then ...;
Run;
However I ran it without the set statement so now I only have X variable
left in the whole dataset. Could you please help me get back the original
data? The table is a SPDE table and has millions of rows. Kindly reply asap
if anyone of you know the method or have any pointers. Thanks in advance.
Regards,
Mihir Vora
