Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: r(110) error with -svy-, -mark-, -marksample-

From   Nick Winter <[email protected]>
To   [email protected]
Subject   Re: st: r(110) error with -svy-, -mark-, -marksample-
Date   Tue, 31 Jul 2012 21:33:38 -0400

Another approach would be to exile the variable creation code to a separate do file from the -save- command. Something like:

* ---

use dataset
... some manipulations
do uglycoding
save myfile

* --- end

* ---

forval ...
    tempvar ...

    ... calculations ...

* --- end

Then the coding all gets done with a single call to, which calls The tempvars are then local to, and are automatically dropped when it ends, allowing to resume, and to save a clean dataset.

Nick Winter

On 7/31/2012 9:10 PM, Stas Kolenikov wrote:
They were dropped automatically, but you could not benefit from it.
Entertain this:

-- --

sysuse auto, clear
tempvar one
gen byte `one' = 1
save auto_one, replace

-- end of --

At the completion of, you won't see any tempvars
(although -describe- would indicate that the file has actually
changed). But the saved version will contain whatever was present at
that spot in time, including the ugly named __000000 or whatever the
available -tempvar- name will be. So -capture drop __00*- may often be
a good idea (you want -capture- just in case that there was no temp
crap left, otherwise -drop- would produce an error).

On Tue, Jul 31, 2012 at 5:43 PM,  <[email protected]> wrote:
Thank you, Stas!  Your supposition explains the behaviour observed
(including why it worked ok on 12 July 2012).

There were a load of temporary variables created in the process of
making my "voldat.dta" data set. But I had simply assumed that they
would have all disappeared when the data creation do file had
successfully completed. And they it turns out that they hadn't. They
weren't in my face as "voldat.dta" is large.

The (non-elegant) code which creates the tempvars is:

quietly {
forval t = 1/18 {
  forval f = 0/1   {
         tempvar temp1
         tempvar temp2
         tempvar temp3
         tempvar temp4

         regress mwage1 A A2 A3 A4 if mwage1 > 0 & !missing(mwage1) &
wave == `t' & female == `f'
         predict double `temp1' if e(sample), residuals
         regress mwage1 A A2 A3 A4 [aw = xrwght] if mwage1 > 0 &
!missing(mwage1) & wave == `t' & female == `f'
         predict double `temp2' if e(sample), residuals

         regress mwage2 A A2 A3 A4 if mwage2 > 0 & !missing(mwage2) &
wave == `t' & female == `f'
         predict double `temp3' if e(sample), residuals
         regress mwage2 A A2 A3 A4 [aw = xrwght] if mwage2 > 0 &
!missing(mwage2) & wave == `t' & female == `f'
         predict double `temp4' if e(sample), residuals

         replace mwage1res_u = `temp1' if mwage1 > 0 & !missing(mwage1) &
wave == `t' & female == `f'
         replace mwage1res_w = `temp2' if mwage1 > 0 & !missing(mwage1) &
wave == `t' & female == `f'
         replace mwage2res_u = `temp3' if mwage2 > 0 & !missing(mwage2) &
wave == `t' & female == `f'
         replace mwage2res_w = `temp4' if mwage2 > 0 & !missing(mwage2) &
wave == `t' & female == `f'

I've now added a -drop __*- line after this section, and the temporary
variables are no longer retained in "voldat.dta". And the job with the
call to -idonepsu- now works again.

I remain surprised that the tempvars weren't automatically deleted at
the end of the data creation job.

 From   Stas Kolenikov <[email protected]>
To   [email protected]
Subject   Re: st: r(110) error with -svy-, -mark-, -marksample-
Date   Tue, 31 Jul 2012 17:19:23 -0500


The most obvious explanation is that you do have that __000003
variable present in your data set, for some strange reason (the data
set was saved while -tempvar- was created, but before it was cleaned
with an exit from a program). Sometimes, I do get something like that
with a complicated set of nested routines and some complicated
patterns of who creates and who cleans the -tempvar-s, although I
would expect that Stata would try to come up with the next available
-tempvar- name upon having checked that a variable already exists in
the data set. The conflict like that may also arise if you
deliberately drop a tempvar rather than let Stata do it. But it would
be strange if this error were in the official code.

On Tue, Jul 31, 2012 at 4:59 PM,  <[email protected]> wrote:
I am unable to run some -svy- related commands using one of my data
sets. The puzzle is that I have no problems with similar commands
applied to data from the Ref Manuals (cf. example below: uses

The issue: after -svyset-,  -svy: ...- commands produce a r(110) error

[P]     error . . . . . . . . . . . . . . . . . . . . . . . .  Return
code 110
         __________ already defined;
         A variable or a value label has already been defined, and you
         attempted to redefine it.  This occurs most often with
But I had made no such attempt to redefine, as far as I know. With
trace on-, it seems that the command applied to my data is choking
it makes a call to -marksample-. There's an example below: uses

In another example (not shown), I had been using -idonepsu- (command
deal with singleton PSUs; on SSC), and also hit the same error, though
this time with a call to -mark- according to a -set trace on-.  [Even
more strangely (to me), I have a log file from a job also using
-idonepsu and same data set, dated 6 Jul 2012, that ran without
Any ideas?

Stata 12MP/4, fully updated. Behaviour observed on Win7/64bit and Win
. display "`c(tmpdir)'"


Professor Stephen P. Jenkins <[email protected]>
Department of Social Policy
London School of Economics and Political Science
Houghton Street, London WC2A 2AE, U.K.
Tel: +44 (0)20 7955 6527
Changing Fortunes: Income Mobility and Poverty Dynamics in Britain, OUP
Survival Analysis using Stata:
Downloadable papers and software:

Please access the attached hyperlink for an important electronic communications disclaimer:

*   For searches and help try:

*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index