John,

Your discussion gets to what I consider the heart of the matter, an app that you found you could only successfully complete with VFP.

The hardest part for me in that scenario, is knowing that usage of VFP has dropped substantially in the last few years. And seeing developer camps where another tool is used that are hugh compared to VFP ever was and ever will be.

The question that begs my mind is twofold, 1) Could this task be accomplished with tools that you didn't have success with, such as Java and .Net, if you had a developer with the right knowledge, or found a source for changing your development strategy that would allow you to accomplish the task and 2) Or are you absolutely correct, the task you needed to solve could only be accomplished with VFP. And this means that VFP is the correct tool for a particular scenario.

I also have questions about your statement about the developers that just don't know what their missing by not using VFP. I just seen too many developers leave the VFP camp for greener pastures, and I have yet more then 1 or 2 return.



>Rod,
>
>I think it depends what you mean by "manipulation".
>
>Lots of stuff out there provides the features of a highly scalable, customized, enhanced spreadsheet with pivot abilities. Many batch entry, financial/billing apps fall into this category. Please accept I'm not criticizing, I'm just segregating app types! IMHO the real value in such apps comes from smart UIs, business awareness and featuresets, not the precise technology used to provide the views. Clearly the market agrees- check out which "modern" technologies are used by many banks and financial institutions. When they upgrade, it won't be because their current 25-year-old technology needs better data manipulation features.
>
>I'm more talking about scenarios where data is more based on meaning and relationships between items and collections of data rather than column values and expressions. Relationships can span dozens or even hundreds of rows in the same dataset. Artificial Intelligence is in this domain, as is some of the newer clinical care planning work.
>
>Can it be done in C#? Yes- I should know, we did some of it starting in 2002. But we struck immediate hurdles because ADO.NET was memory resident. You say you've done some large row manips: lets be fair, they're small rows, or you had far more memory than a standard business machine, or both. And did you open a huge resultset several times with variably filtered results, index some of them, then compile a report that could be refreshed almost instantly by the user changing a parameter in their UI? If you did, I'll bet you did it at the server. We tried that too, and it brought the server to its knees with just a few users. Whereas a local VFP cursor delivered blazing performance with no network, server or PC resource hogging.
>
>IMHO there are some things VFP is just good at. Surely we agree I need to be able to say this, just as dotNETties need to be able to say what they like about their new tool. FWIW, MS says dotNET will soon be good at the stuff that draws many of us to VFP. Excellent! If nobody spoke out, perhaps that would never happen.