Multiple m:1 merges

[Taylor Walter]

Hi all,

I'll try to keep this as brief as possible, and I don't know if -dataex- is even needed here: basically, I successfully used -merge m:1- at the beginning of my programming for a panel dataset, then did a bunch of stuff to it, and now towards the end I have to do another -merge m:1- for different data than the first one.

But when I do -merge m:1- the second time, I get the error "variable _merge already defined", which makes sense given that I already did a merge earlier on. Perhaps there is some easy workaround that I am not aware of, or a way to do multiple m:1 merges at once? Thanks.

[Clyde Schechter]

Well, you can just -drop _merge- before you run the second (and each subsequent) -merge-. Or, in your -merge- commands (including the first) you can specify the -nogenerate- option. That will keep Stata from creating the -merge- variable at all.

I generally prefer the first approach, because I usually like to see the display of _merge value that Stata provides to make sure that things are matching up the way I expect them to. I generally resesrve the -nogenerate- option to situations where I have also specified the -assert()- option so that Stata will stop and complain if the matchups aren't coming out the way I think they should. I would not want to have a series of -merge-s and not find out until later on that two data sets that I thought paired up in a certain way did not, in fact, do so. Fail early and often!

Added: Another workaround is to, in the second and subsequent merges, specify the -generate()- option, specifying each time a different variable name to receive the information that Stata would otherwise, by default, place in a new variable named _merge. This means that at the end of the entire process, all of the data about the pairings at each -merge- is available for you to check. I never use this approach, because I prefer to trap problems as soon as they occur, not accumulate them and then try to disentangle them. But it is possible to do it this way if you prefer.

[Taylor Walter]

Sometimes the most obvious solutions are the hardest to think of. Thanks for all of the extra advice, as well.