undo command

[maen assali]

Hello all,

I have a question, would it be possible to undo last command, say I entered drop Age (variable) and I entered that command in mistake, is there a way to tell stata to undo that command?

[Clyde Schechter]

Unfortunately, you cannot undo a -drop- command.

Not that it will help you at the moment, but you should practice a workflow that prevents you from ever being in this situation. In particular, unless you are just "playing around" with something that is "quick" and has no real importance, you should always work in a do-file. Enter your commands in the do-file and run them. When you are done with a working session be sure to save the do-file so you can repeat it whenever you need to, and can refer to it to figure out what you have done when it has faded from your memory. Also, and this is important, if your do file creates a new data set from an old one, do not overwrite the old data set. Save the new data set under a new name and be sure not to delete the old one. That way, if you discover you made a mistake, you can recover.

If you find you have included a command by mistake, just go back and delete that command, then re-run the do-file from the beginning. It'll lose you a little time, but you will never lose data that way.

[maen assali]

Unfortunately, you cannot undo a -drop- command.

Not that it will help you at the moment, but you should practice a workflow that prevents you from ever being in this situation. In particular, unless you are just "playing around" with something that is "quick" and has no real importance, you should always work in a do-file. Enter your commands in the do-file and run them. When you are done with a working session be sure to save the do-file so you can repeat it whenever you need to, and can refer to it to figure out what you have done when it has faded from your memory. Also, and this is important, if your do file creates a new data set from an old one, do not overwrite the old data set. Save the new data set under a new name and be sure not to delete the old one. That way, if you discover you made a mistake, you can recover.

If you find you have included a command by mistake, just go back and delete that command, then re-run the do-file from the beginning. It'll lose you a little time, but you will never lose data that way.

Great tips, thanks for the guidance!

[Sven-Kristjan Bormann]

Another possibility is to use the combo of -preserve- and -restore- to test commands without changing the underlying dataset. So you first issue a -preserve- command to keep copy of the current dataset available. Then you play around with your data. If you notice a mistake like a wrong -drop- command, then you just issue -restore- and a new -preserve- command to undo the changes. Once you are happy with your intended changes, then you restore the dataset, but this time run your intendeded commands without the -preserve- command.

I do something along the above line whenever I want to try out something without knowing before, if I want to save the command for later usage in a do-file.

[Clyde Schechter]

If you notice a mistake like a wrong -drop- command, then you just issue -restore- and a new -preserve- command to undo the changes.

Actually, you can combine those into a single command

restore, preserve

which both restores the original data set and keeps the preserved copy alive.

It's also faster than doing -restore- followed by a separate -preserve- command because you do not erase the first preserved copy and then write a new one. If the data set is large, the time difference is noticeable.

[Sven-Kristjan Bormann]

Thanks for the hint. I never really considered using -restore, preserve-, but in the future I will give it more thought when dealing with larger datasets.

[maen assali]

Another possibility is to use the combo of -preserve- and -restore- to test commands without changing the underlying dataset. So you first issue a -preserve- command to keep copy of the current dataset available. Then you play around with your data. If you notice a mistake like a wrong -drop- command, then you just issue -restore- and a new -preserve- command to undo the changes. Once you are happy with your intended changes, then you restore the dataset, but this time run your intendeded commands without the -preserve- command.

I do something along the above line whenever I want to try out something without knowing before, if I want to save the command for later usage in a do-file.

Awesome tip thank you!

[Kinjal Gautam]

Unfortunately, you cannot undo a -drop- command.

Not that it will help you at the moment, but you should practice a workflow that prevents you from ever being in this situation. In particular, unless you are just "playing around" with something that is "quick" and has no real importance, you should always work in a do-file. Enter your commands in the do-file and run them. When you are done with a working session be sure to save the do-file so you can repeat it whenever you need to, and can refer to it to figure out what you have done when it has faded from your memory. Also, and this is important, if your do file creates a new data set from an old one, do not overwrite the old data set. Save the new data set under a new name and be sure not to delete the old one. That way, if you discover you made a mistake, you can recover.

If you find you have included a command by mistake, just go back and delete that command, then re-run the do-file from the beginning. It'll lose you a little time, but you will never lose data that way.

Thank you for this! Do you mean that we should create a new dataset every time we make a significant edit to an existing dataset?

[Hemanshu Kumar]

Welcome to Statalist, Kinjal!

I save datasets only at significant checkpoints in my code. If there is code that takes a long time to execute, and you don't want to have to run it again and again, then save the dataset and use that dataset from then onwards, rather than the original dataset. For example, you may have done a bunch of processing and prepared the data to be able to run certain estimation commands or produce some figures etc. In that case, save the dataset, and have the code for the estimation or figures start from that dataset instead of doing the preparatory processing every time you want to tweak the graphs or regressions. But no, I would not usually save a new version of the dataset just because it looks significantly different from the original.

[Clyde Schechter]

Do you mean that we should create a new dataset every time we make a significant edit to an existing dataset?

The word "significant" is doing a lot of work in that question!

For me, the decision whether to save a modification of a data set depends on two things:

1. Does creating the modification take a lot of time?
2. Will this modified version of the data set be needed again?

If the answer to both of those questions is yes, then I definitely save the modification. I never delete or overwrite earlier versions. (I may compress them and store them on a removable storage device, if I don't think I will need to use the earlier version again any time soon. But they are always preserved somewhere.) If the answer to either question is no, I generally will not save the modification. Let me qualify that a bit. It is often difficult to predict whether the modified version of the data set will be needed again. So if the answer to question 1 is yes and I am not highly confident that the modified version will not be needed again, I might save the modified version "just in case." And the longer it takes to create the modification, the more certain I need to be that it won't be needed again to decide I won't save the modification. But, and this is important, if I do save the modified data set, I always give it a new name: I never overwrite or delete the data set that I started out with. That way, if I find that I made an error in creating the modification, I can at least revise the code and do it over. Also, if subsequent work with the modified data set leads to problems that cause me to question whether the data I'm using is correct, I can go back to the source data to see if that's how the data was when I got it (in which case I turn the solution of the problem back to the person who gave me the data) or whether the error is due to something my own manipulations caused, in which case it is on me to fix it.

[Hemanshu Kumar]

To add to my earlier post and clarify, when I talked about saving datasets, I absolutely did not mean overwriting the original data.

In my projects, the data sits in one of three main folders: input, temp and output. input has the "original" primary or secondary data obtained from my survey, experiment, and/or from external sources. The files in this folder are sacrosanct and never changed -- this is essential for reproducibility. The data files I create using my scripts (do-files) all go into the temp and output folders. As the code develops, I may make different calls about what to save, what to overwrite, etc in those folders. But at any time I know that nothing is really lost if I were to completely delete everything in the temp and output folders -- everything in them is created from the input data using my scripts.