Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
From | Wayne Folta <wfolta@mac.com> |
To | statalist@hsphsun2.harvard.edu |
Subject | Re: st: Bug in Stata 13 (Mac) with compress duplicating variables? |
Date | Mon, 05 Aug 2013 08:00:58 -0400 |
Sergiy, Good points! I found yet another lurking duplicated variable and decided to try to save as dta-format XML and then edit the file by hand. I found that sure enough the duplicated variable had duplicates in all areas (name, format, label, etc) but the problem is that the DATA section of the XML file is stored in row-major order with no variable identification, which made it tough to edit in such a way as to eliminate the variable and its data. I ended up dropping the variable in Stata -- which only seems to drop the first copy -- and I think everything's OK. I'll double-check by outputting XML with extra formatting. As I was writing this, I went back and tried the dta-format XML export with the "extra formatting" checkbox checked, and it does include the variable name with each data item, which would make it much easier to edit the XML in an editor (with grep capability) to totally eliminate a variable. N.B. Wayne On Aug 3, 2013, at 11:40 PM, Sergiy Radyakin <serjradyakin@gmail.com> wrote: > Wayne, > > the problem you describe is then the problem of R's 'foreign' package > and not Stata's. > > Indeed, Stata is known to conduct only minimal checks when loading a > file. It will tolerate many problems in the data that are not > permissible under Stata's rules. Despite loading such problematic > files without an error or a warning Stata then may break down later > on, when trying to process such data. > * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/faqs/resources/statalist-faq/ * http://www.ats.ucla.edu/stat/stata/