Statalist The Stata Listserver


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: RE: RE: statalist-digest V4 #2718 / Stata 10 announcement


From   "Newson, Roger B" <[email protected]>
To   <[email protected]>
Subject   st: RE: RE: RE: statalist-digest V4 #2718 / Stata 10 announcement
Date   Tue, 5 Jun 2007 14:25:37 +0100

For what it's worth, a possible fix to the problem of between-version
portability in .dta files might involve the -descsave- package,
downloadable from SSC using the -ssc- command in its Stata 9 version,
and from my website by typing in Stata

net from http://www.imperial.ac.uk/nhli/r.newson/stata8/

for the Stata 8 version, and by typing

net from http://www.imperial.ac.uk/nhli/r.newson/stata7/

for the Stata 7 version.

The -descsave- package is a Stata program that writes Stata programs,
which are compatible (to the best of my knowledge) with Stata versions 3
to 9, and which can restore the storage types, formats, variable labels,
value labels and characteristics of Stata variables after they have been
written to and read from a generic format.

For instance, a user of Stata Version xx on Machine 1 might want to port
a dataset to Stata Version yy on Machine 2. This user might type, in
Stata xx on Machine 1,

describe
descsave, char(*) do(revive1.do)
outsheet using generic1.txt, replace

This would generate the generic spreadsheet generic1.txt and the Stata
do-file revive1.do, both of which would be ported to Machine 2. The user
would then type, in Stata yy on Machine 2,

insheet using generic1.txt, clear
run revive1
describe

This would cause essentially the same dataset (with possible minor loss
of precision) to be recreated in Stata yy on Machine 2, using the
program revive1.do to reset variable attributes. My colleagues have used
this method to port Stata datasets from Version 9 to Version 6 with no
major problems, to the best of my knowledge.

I hope this helps.

Roger


Roger Newson
Lecturer in Medical Statistics
Respiratory Epidemiology and Public Health Group
National Heart and Lung Institute
Imperial College London
Royal Brompton campus
Room 33, Emmanuel Kaye Building
1B Manresa Road
London SW3 6LR
UNITED KINGDOM
Tel: +44 (0)20 7352 8121 ext 3381
Fax: +44 (0)20 7351 8322
Email: [email protected] 
www.imperial.ac.uk/nhli/r.newson/

Opinions expressed are those of the author, not of the institution.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Joseph
McCrary
Sent: 05 June 2007 13:51
To: [email protected]
Subject: st: RE: RE: statalist-digest V4 #2718 / Stata 10 announcement

First of all, Stata Corp is one of the last ones I would ever associate
with
poor customer relations. How many other companies participate in
discussion
lists that they themselves do not moderate? Few. Very Few. 

Also, I've dealt with the people from Stata on several occasions for
problems that were specific to my previous organization's specific
501(c)3
compliance requirements. They spent a lot of time on it, and it only
affected the sale of about 5 licenses, so it's not like they got a lot
of
bang for that buck. 

And good luck trying to get one of the behemoths to spend any time on
the
phone with you, and then actually give you answers that made sense. One
of
the statistics behemoths with a four-letter acronym once told us that
their
reversal of inner and outer joins in a release of their program was a
"feature," not a bug. And this was about 2 months after we reported it
and
supplied them with the data and code. Doubt we would have gotten that
same
response from Stata (or that they would have made such a basic error).

Second, there are probably 2 versions of Stata (v.8 and v.9) that are
very
active in the field, plus a couple more that are still used extensively
in
places that cannot afford upgrades. Should Stata write code for each
version
to read in data from all future versions? When does it stop? And what
will
that do to the cost of future upgrades? If version 10 needs to be
compatible
with version 9 and version 8, then Stata Corp has to go back and write
code
for version 8, what, 3 years after they've stopped writing code for it?
And
then how bloated will Stata be (note how many people complain about
Microsoft products being bloatware)?

Third, you wrote:

Since the code to read a new format file and to write an old format file
must exist within Stata 10, what is the problem in adding a module "read
Stata 10 file" to the last update of version 9?  

It's not the same thing. If a Stata 10 file has already been read into
Stata
10, then any existing Stata 10 specific code is already incorporated.
There's only one step to convert into an older version. However, to read
a
Stata 10 file into a previous version of Stata, it has to be able to
translate any headers, parse out each variable and ensure that the
variable
conforms to the older version, and convert variables into something that
is
consistent with the old version (and hope that it is what you thought it
would be). 

Again, this would increase the cost of Stata. And who pays--the person
buying the new version because other people don't upgrade? That's not
fair
to them, is it? Or do you just build it into the cost of the upgrade in
case
the user decides not to upgrade, driving the cost to everyone up? 

No, the efficient answer is the -saveold- command. 

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Allan Reese
(Cefas)
Sent: Tuesday, June 05, 2007 8:03 AM
To: [email protected]
Subject: st: RE: statalist-digest V4 #2718 / Stata 10 announcement

Alan Riley replied to Richard Williams on behalf of StataCorp: We will
in
fact put out a final update to Stata 9, likely shortly after Stata 10
ships.
However, this update will not include the ability to read Stata 10
files.
As Nick pointed out, our solution for users who need to share datasets
across versions is the -saveold- command.
---

With respect, that is what I call the Microsoft attitude: we assume
(know /
instruct) that everyone will upgrade and willingly accept any changes
that
we've made.  "Poor relations" who can't keep up will have to rely on
"proper" users remembering to adapt their hand-me-downs.

It incidentally shields the "poor relation" from knowing what was lost
when
the file was converted to old format.

Since the code to read a new format file and to write an old format file
must exist within Stata 10, what is the problem in adding a module "read
Stata 10 file" to the last update of version 9?  Or was the stuff I was
taught about modular programming in the 1970s just hot air?

It's made me wonder whether the guy carving the Rosetta stone was
muttering
the whole time, "Why can't these old Egyptians just learn Greek?"

Allan  


************************************************************************
****
*******
This email and any attachments are intended for the named recipient
only.
Its unauthorised use, distribution, disclosure, storage or copying is
not
permitted.  If you have received it in error, please destroy all copies
and
notify the sender.  In messages of a non-business nature, the views and
opinions expressed are the author's own and do not necessarily reflect
those
of the organisation from which it is sent.  All emails may be subject to
monitoring.
************************************************************************
****
*******


*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/

*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index