>
Why might I choose this route? Because my client side code is classic VFP, with just a few changes in the data environment. Controls are bound to VFP cursors, multi-record validation code (that might use SCAN, or GO) still works. My grid class that resorts when you click on the header still works. All this stuff works with almost no changes in client code, only by replacing a dataenvironment class with one that pulls data from and submits data to a middle-tier component on another machine. My VFP forms are none the smarter, and its completely n-tier, and completely ready for a VB, C++, or even a Java client running on a Sun box. It all runs over HTTP. I would submit that this method is even more generic than serving up Recordsets from the middle-tier.
>

Good work. It stands to reason that if you are going to use a client that has some intrinsic ability, it makes sense to make use of those abilities. So long as it does not affect the middle tier - I would say your design is sound. If you built a UI layer to interface the UI and middle-tier, I say bravo. By the same token, I would also say that making VFP form's data-source agnostic is not a revolutionary idea. It has been done before...

>
This is a valid and sound argument, just not sure if it's relevant. But thanks for the verbal notification that this thread has mutated from "cursors shouldn't be used on the client" to "VFP is dead".
>

Despite being good technology - if there is no market for it - it is useless. Is VFP dead? Let's just say that the while the fat lady is not singing, she is clearing her throat...


>Again, IMO, data access technique has little to do with how the data is used by business logic.
>

OK....


>
Me too. But I do know for sure that I'm going to have a go with it. Curious, if you decide that .NET is .NOT, what language/platform would you go to?
>

The jury is out, but you know for sure that you are going to have a go with it? OK, I would say give it a try. However, I would not dive in head first...


>
It's not the only tool I know, but it's definitely the one I know best. I have written a few small projects in VB, built a few utilities with it, and studied a lot of sample code and strategy articles, and I think I know enough to be able to reasonably compare VB and VFP, and I still think that VFP handles most things more gracefully than VB does. That's why I continue to use VFP when I have a choice.
>

VFP handles things more gracefully for YOU because you know how to make it more graceful than VB... It is an issue with the developer - not the tool per se...


>>I think it is because whether you realize it or not, you are limiting your


>
I realize this, and am trying to provide for both. VFP is making me a pretty good living right now, but I realize that its future is in question, so I try to concentrate my learning in areas that apply to all languages.
>

It is good that you realize the future of VFP is in question....



>
As an aside, in case you hadn't noticed, the future of VB is not in question, VB as we know it has already been given its death sentence. AFAIC, my skills in VFP have a longer useful life than the next guy's skills in VB6, because he will be required to learn an entirely new programming strategy and syntax by the next release of VS.NET.
>

I think that is bullshit - no offense..< bg >.. Seriously, I think a lot of people are going to stay in VB 6. What compelling reason is there to upgrade to VS.NET?


>
Perhaps. But I only started with Fox about 3.5 years ago, and I have a feeling the best days were gone before I got here. It didn't keep Fox from building my house though. :-)
<

Hey, at least you think with your wallet!! That I respect!!

Best...

< JVP >