>>>>I haven't seen the list in the chm, but I have seen the one posted at http://download.microsoft.com/download/e/f/f/efff372d-5f27-414c-ae18-177170bf676d/vfp9sp2_bugfixlist.htm, which is not a cumulative list.
>>>>
>>>>>This may be a dumb question, but in the htm file there is a bug fix list and says these bugs have been fixed in sp2 and then there is a long list of bugs including many prefixed with VFP6,7,8 etc
>>>>>
>>>>>? Does that mean these are the first time they've been fixed or is this a cumulative list of every bug that has been fixed since VFP 6 or ??
>>>
>>>So does that mean the bugs marked vfp6 etc have been around since 6 and are just fixed now?
>>
>>Well, one of the few bugs I submitted recently has the vfp7 heading - probably introduced then.
>>But what about another bug I submitted, which is now headed by "FoxPro". Probably found a very well hidden sleeper <g>...
>
>I'm actually kind of nervous about applying this. I figure resource allocation at MS for Foxpro right now means there may be as much as 4 man hours of testing on this <s>

It is another phase for vfp, for sure. But in the couple of years I have used FoxPro and Vfp I only once encountered a bug I could not find a statisfying workaround for. That was back in vfp6 times, where the use of transactions in a client conceived fwk created CHR(0) filled records through record pointer movement during transactions - we had to disable transactions, as rewriting a big part of the data and biz layer was considered too dangerous (by managment, I would have called it a very interesting chance of refactoring<bg>), as most of the clients used to SW in road-warrior scenarios without multiple users. For the rest using tableupdate with some pesimistic locking on important tables was good enough - but it was so much of a patchwork I would not consider it a *satisfying* workaround<g>.

But I will try to keep vfp9 SP2 the only version I am actively coding for, as arguing to upgrade to the last official version support is promised to should be easy - the alternative being a rewrite in another language or at least a switchover to either .Netcompiler for vfp or Christoph's vfp-interpreter for .Net. Leapfrogging versions (as I did for instance with vfp7) in not really an option now<bg>. Even those 2 tools will probably strive for compatibility at that level, as this should enhance their marketing chances.

And a large part of testing is automated by now - the man hours get you more mileage.

regards

thomas