>I guess we are on the skepticism bandwagon over the state of VFP and what M$ wants to do with it. Here is what brought us to this side of the table (comments, suggestions and insight are appreciated). We led the charge to convert to VFP 6.0 and VS 6.0. In retrospect, we should have relied on our experience with upgrades but our intuition suggested that this upgrade shouldn't be any worse than 5.0. Well.. . ..
>
>1) We became the victims of one of the 17 first documented bugs. When you execute multiple SQL queries in a group of code, each subsequent query "suffers a degradation in speed to complete the query". The degradation was double the speed in our experience. Trust us that we tested the same code and data on the same machine, and tried to give both 5.0 and 6.0 the benefit of the doubt as to comparable operating environments. M$ solution(interim) was to change all "where" statements to "having" and that would solve the problem. Well....... it now takes between 3 and 4 times longer to execute the query in 5.0 vs. 6.0
>
>
>2) An undocumented bug from M$ standpoint (Not on UT where it is discussed) involves getting a fatal error C0000005 that we don't get in VFP 5.0. Here's how it happens. A view is executed, within a page of a pageframe where one of the table joins is a left outer join to a table where only a small number of parent records will contain a valid reference to this lookup table. If a .null. is returned, space(2) is inserted in the field displayed. When the query executes, if the data set encounters a null on this field (based upon a foreign index integer id of 0 in the field), the fatal error is generated and VFP has to shut down. If a non-null value is located, the information displays correctly.
>
>Our UT research is that the same error was being received but that it had to do with display of information and that some had solved it by installing IE 4.1 and/or dcom98 (both on the VS CD). Well, neither has solved this problem and we find ourselves kludging a solution for it to work in 6.0.
>
>There are other "hard to prove without more testing but we know there is a problem" situations in 6.0 which do not have to do with old features. The bulk of these problems all tranlate into serious processing speed issues of 5.0 vs. 6.0. WHY????? Why are they breaking something that doesn't need to be fixed?
>
>Is M$ degrading VFP to the point that it is competitive with VB? What is the plan. I'm exhausted thinking about it.

There are bugs in VB 6.0, too. And there are more serious issues than what you note; problems in the thread model, and problems with COM objects stepping on each other's Data sessions, that are far more important to me at least.

The C0000005 error is an operating system level trap of a memory access error; it's not a single problem that is universally fixable (IOW, although the C0000005 error seen in the "SCREEN=_OFF" problem may be fixable by installing DCOM, that does not mean that all C0000005 errors are corrected by this action.)

I seriously doubt that bugs in VFP 6.0 are M$'s way of trying to wean people off VFP - VFP 6 has gotten a ton of favorable press, and M$ is making some efforts to create a niche for VFP in the VS environment, at least from a marketing standpoint.

>
>Anybody in the know out there? Let me down hard now, rather than dragging me out and trying to let me down easy.