Problem with "Graph already exists" message

[Eddie Brighton]

Dear Statalist,

I'm having problems with clearing graph memories even after using the "graph drop _all" command. I still encounter the message "graph XX already exists." Anyone has an idea? Thanks.

[Clyde Schechter]

I think you need to show the block of code, exactly as you are trying to run it. It sounds like you are mass producing graphs in a loop (or something like that). It may be that there is something wrong with the iteration structure of the loop that is causing the same name to be used twice after the -graph drop _all- command has already run. But without seeing the code you are running, this is just a guess, and, in any case, doesn't necessarily help you figure out what is wrong with the iteration structure of the loop. Please do post back with the code.

[Eddie Brighton]

Thanks, Clyde. I think you're right. Apologies for not showing the code.

local list DD VA TR HS AG IN DJ SZ HE CM GS DL HU DN EP NN TD SB ST ED OM NU
foreach i of local list{
    twoway bar number_of_selections_made_off_th announcement_open_ym if agy=="`i'" & socal!=0, ytitle("") xtitle("Year/Month") lwidth(0) barwidth(0.7) tlabel(2018m9(1)2021m12) xlabel(, angle(90)) xlabel(, labsize(tiny)) ylabel(, angle(0)) title("`i'") name(`i')
}
graph combine `list', ycommon

where number_of_selections_made_off_th indicates the number of hirings, announcement_open_ym time (year/month), and DD ~ NU name of the organizations.

[Clyde Schechter]

Well, I cannot replicate your problem. The iteration structure is simple and it does not contain any duplication. I created a toy example modeled on what you did, and apart from having to remove the -tlabel()- option because my toy model didn't include a time variable, it runs with no error messages at all, and ultimately produces a matrix of 22 small reps in a single graph. So I don't know why you're having that problem.

Now, you don't actually show the -graph drop _all- command in #3, so it is possible that something you do between -graph drop _all- and the code you do show in #3 is creating a graph with a name that matches one of the words of -local list-. Otherwise, I'm at a loss.

Added: Just tried another toy example that does have a time variable in the graphs and includes the -tlabel()- option. It still runs perfectly.

Sorry, but unless there is something going on between -graph drop _all- and the code shown in #3, I can't see a cause for the problem. If you want to post all the code from -graph drop _all- to the code in #3, I'll be happy to look at it with a view to finding the problem there.

[Hemanshu Kumar]

Just change the name option to name(`i', replace) ?

[Eddie Brighton]

I think it had something to do with "creating a graph with a name that matches one of the words of -local list-," as Clyde suggested. Problem solved with Hemanshu's suggestion to use replace. Many thanks to both of you.

[Nick Cox]

If you have used a graph name before in the same session, you need to flag replace.

[Clyde Schechter]

Re #5, #6 & #7: not so fast!

The original post says that this was all preceded by -graph drop _all-. In that circumstance, there should be no need for a -replace- suboption, and using it is just covering up the fact that something has gone awry between -graph drop _all- and the loop. Somewhere in there, something must have happened that created a graph with a name matching some element of -local list-. If that wasn't supposed to happen, then O.P. should fix the code so that it doesn't. It may be that that is supposed to happen, and perhaps the content of -local list- mistakenly contains an element that shouldn't be there because it was already taken care of by some other kind of -graph- command. If that is the case, then adding the -replace- option will cause the original graph to be lost and clobbered by an incorrect one.

In any case, the problem is by no means "solved." It has, rather, been swept under the rug.

[Nick Cox]

I think #7 remains true and #5 remains good advice. The puzzle still is, as Clyde said straight away, that we don't have a reproducible example. I would think it most likely that we don't have a complete report of what happened.

[Hemanshu Kumar]

I agree that the issue has been swept under the rug and not solved. But sometimes time is of the essence and you need the problem solved even if not fully diagnosed. #5 achieves that without doing anything destructive (since OP only appears to care about the graphs being produced in this loop, not anything before). We have neither the full code, nor the exact error (I would be curious what the XX is in "graph XX already exists"), nor the exact sequence of events (e.g. was only part of the code being executed at any time?) to diagnose the problem per se.