I agree with the thrust of your logic, George, but do have a comment or two.

1) Some workarounds can be detrimental to code in the longer run. A workaround generally stays in code long after the proper fix is available. A complex "workaround", though legitimately a "workaround", can be detrimental to performance (even an easy one can) and make code difficult to grasp in later maintenance.
Some other "workarounds" can be detrimental to VFP itself. Some bugs are enough to keep people away from VFP7, their "workaround" being to stay with VFP6 or earlier.

Any bug that jeopardizes data integrity is a critical bug, even if it happens only once every 9 months in any shop.

We have "service packs" and we have "hot fixes" and there no doubt are other mechanisms too. I've always wondered why MS couldn't release a fix (or group of them) when they were remedied rather than wait for a new release to let us have them.

regards

>Tom,
>
>Let's put the lack of an SP2 into perspective. In order for a service pack to be necessary, I believe that three criteria have to be met: First, severity; Second, frequency; and Third, degree.
>
>Let's tale these in order.
>
>Severity - How serious is the problem (or bug)? Does a simple workaround exist? If the answer to the first question is "very", but the answer to the second is "yes". Then the need for an SP is reduced. If a workaround doesn't exist, then we must check the second criteria. Otherwise, an SP isn't necessarily in order.
>
>Frequency - How often in the course of application development does this occur? If it's often, then we can proceed to the next criteria. However, if it's a once in awhile thing, then there probably isn't the need for an SP.
>
>Degree - How many instances rate high in both severity and frequency? Let's be frank, issuing an SP to fix only one or two bugs, isn't going to happen.
>
>What Microsoft is saying to us regarding a possible SP2 for VFP 7.0 is that there aren't currently enough issues that are high enough on the above scale to warrant it.