>Snip:
>"VFP didn't pull in the dough for them once it was sold. They couldn't milk it for extras (free runtime distribution, no user licenses, etc.) so that was a pretty simple decision. It couldn't go away fast enough for them."
>
>Swap 'VFP' for '.NET' Which of the above sentences does not apply ? :-}


Fair statement, but, right out of the box VFP give everything one would need to build a complete app including a database (even if some don't considered it a "real" one) and report writer.

Now you could argue that .NET can hook up to any free version of a "real" database and I believe that a version of Crystal reports is included, but from my experience with developing applications (and they would not be considered enterprise apps) .NET would be overkill for me. It is this scenario that I feel is where VFP is not being accurately accounted for when the numbers game comes up. For example, I wrote a small POS app in VFP for a friend's restaurant about five years ago. It was simple to develop and runs on a single computer (a low end Pentium II that I gave them that I no longer cared for) setup with a touch screen monitor and thermal receipt printer. It runs 7 days a week during business hours almost every day of the year. To date, I've never had to fix it due to "DBF errors". It just works for them the way they want. Everything I needed to complete this app was in the VFP box except Windows and the printer and monitor drivers :)

Does it need to be converted to .NET? Nope. Does my friend know what it is written in? Nope. Do they care? Nope.

I wonder how many VFP apps like this are being used globally? How can we tell? I don't think we can and neither could MS.