I agree to Nick's earlier comment about sharp knives. I do not agree
to Nick on the point that it is easy to write a wrapper around
"preserve" that would properly issue warnings, that Martin wishes. If
I write a safepreserve.ado which issues a warning, then preserves,
then whatever it preserved will be restored after it terminates. The
behaviour of preserve is necessarily built-in, since a corresponding
-restore- statement must be issued automatically after the end of the
current block of the program, even if it crashes. AFAIK this behaviour
can not be replicated with legitimate Stata syntax. Something can be
done with tempfile->save->capture{do something}->use,clear But it
restrictively disables all output. (How wonderful programming in Stata
could have been, if -capture- didn't do two things at once:
1. suppress the output
2. get the error code
These tasks should be performed by two different commands)
2Martin: the situation is directly opposite to the Windows Clipboard
(where the contents is lost when you copy the new content there
without any warnings). -Preserve- protects the data which is currently
in the memory, but not the source of the data that has been preserved.
Once you "preserve" any subsequent calls to -preserve- would be
denied, unless you directly specify "restore, not". "Preserve" should
also not be confused with "protect" as Excel understands it
("protected cells"). However, I would really like to see "protected
variables" in Stata, as working with plugins I have been bitten a
couple of times already, when the values were sent to the wrong
variables.
A surprisingly easy way of making sure you don't accidentially harm
your data is to have it read-only (every OS I am familiar with has
such a file-attribute). AFAIK Stata can't modify read-only files, even
if you press Ctrl+S and confirm overwrite or specify "replace" option
after save.
I don't see how logging the actions can protect the data from being
overwritten, and having do-files with same names as dta-files is a bit
idealistic.
Having an option to protect the data that is being opened would be helpful:
//**** here is my turn to be ideallistic :) *****************
use "myfile" , readonly
// keep "myfile" open and protected from writing
// do something risky, which can potentially hurt "myfile"
release "myfile"
//*********************************************************
If release is never issued, file could remain protected until the end
of the session.
Best regards,
Sergiy Radyakin
On 4/20/08, Jeph Herrin <[email protected]> wrote:
> I'm with Svend and Phil - I would never make changes to my
> data except with a do-file. (The only exception is that I
> might -compress- a datafile which I have recieved from someone
> else.) I always name such do-files according to the file they
> -use- and -save-, eg, raw_work1.do would read in a source
> file and save it out as -work1.dta-. Similarly, any analyses
> I want to use are coded in separate do-files, which are named
> accordingly, eg, -analyze1.do-, -tables.do-, etc.
>
> I often have to go back to projects months or even years after
> the paper has been published, and this way I can always figure
> what I did. Plus, I never lose data...
>
> cheers,
> Jeph
>
>
> Svend Juul wrote:
> > Martin Weiss wrote:
> > I was wondering if anyone apart from me has been bitten by -preserve-? I
> > recently preserved data, then dropped half my data to carry out some
> > calculations and later forgot the preserve-status and saved. Now call me
> > foolish, but in the heat of the action, it is easy to forget about the
> > status of your data, isn`t it?
> >
> > So: is there a mechanism to alert me to this danger, and if not, should
> > there be one?
> > Martin Weiss
> >
> ================================================================
> > The most dangerous thing you did was probably not to use -preserve- and
> forget that, but to save your data using the SAME filename as before.
> > Here are a few, very simple, very logical, and very safe rules to follow:
> > 1. Modifications intended to be permanent should be made in a do-file,
> > never interactively.
> > 2. This do-file should start with a command reading data (typically
> > -use-) and end with a -save- command, saving the modified data with
> > a NEW name.
> > 3. Give this do-file a name that tells what it does. My suggestion:
> > use a gen_ prefix: gen_alpha7.do is the to-file that generates the
> > new alpha7.dta dataset.
> > 4. Don't mix data management activities and analysis commands in the same
> do-file.
> > You can find a more elaborate version of this advice in S. Juul: An
> > Introduction to Stata for Health Researchers. Stata Press 2006.
> > Take care!
> > Svend
> >
> > ________________________________________________________
> Svend Juul
> > Institut for Folkesundhed, Afdeling for Epidemiologi
> > (Institute of Public Health, Department of Epidemiology)
> > Vennelyst Boulevard 6 DK-8000 Aarhus C, Denmark Phone, work: +45 8942
> 6090 Phone, home: +45 8693 7796 Fax: +45 8613 1580 E-mail:
> [email protected]
> _________________________________________________________
> > *
> > * For searches and help try:
> > * http://www.stata.com/support/faqs/res/findit.html
> > * http://www.stata.com/support/statalist/faq
> > * http://www.ats.ucla.edu/stat/stata/
> >
> >
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
