> I agree with Richard here. Don't forget that the takeup of a new
> version of Stata sometimes isn't even synchronised within a single
> institution (say, a network version for students vs. the staff
> version vs. the standalone version on a laptop), let alone
> synchronised around the world. The incompatibilities of the .dta
> formats are a nusiance while coauthors, colleagues and students are
> using different versions.
Sure they are. But -saveold- is the StataCorp solution,
which is where we came in.
Stata 7 datasets -> Stata 8: no problem
Stata 8 datasets -> Stata 7: use -saveold-.
I'm not denying here that, depending on set-up, people
can have local or personal problems, and they're not
at all interesting, just frustrating. I'm just guessing
that there are very good reasons why StataCorp will do
nothing extra to help you. Emphasise "guess".
> I don't think making it easier for Stata 7 users to read Stata 8 data
> is going to provide much of an incentive for them to stay with Stata
> 7. Roughly speaking, if they have the budget and want the new
> features of Stata 8 (including the user community's ados), they'll
> upgrade, otherwise they won't.
Yes, both you and Roger Newson raise the extra questions of user-written
programs, directly or indirectly. The user-programmer community tends
to follow a release of Stata with a time lag of just a few months,
so that very quickly most substantial user-written ados are written
for the current release. How much difference that makes to anybody's
upgrade decision I don't know; it's probably marginal. But notice that
the user-programmers in this case are not, so far as I know, following any agenda of
helping Stata's sales effort, and indeed some (like Roger) continue
to make earlier versions of their programs accessible so that people
still using earlier releases can use them. It's just that user-programmers
tend to upgrade very quickly and just can't resist using the extra
features of a new release. Graphics is only the most obvious
* For searches and help try: