>>
>My point was that n-tier and the use of cursors are not mutually exclusive, as you seemed to imply.
>>
>
>I don't think the use of VFP cursors and n-tier are mutually exclusive. The fact is, it can be done. OTOH, I don't consider them a best practice. In most situations, what you need to do can be accomplished with ADO - a technology that is not language specific. Given the choice of technology - one that is language specific and one that is not - all things being equal, I will choose the generic approach.
>

I realize this is straying from the subject, but to demonstrate that client storage strategy is completely independent of the middle-tier input/output format...

My data access component can return several formats of XML depending on a compile time option, including a persisted Recordset.

If you look at my most recent utilities upload here, my xml class has a method that converts ADO XML into a VFP cursor, and it does so fairly quickly.

So my data services tier serves up ADO, but the VFP client never rebuilds the recordset, it just converts it to a cursor.

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.

>You see, my arguments are not based on technology alone.
>
>If I based my arguments on pure technology, my answer would be different. However, what good is technology if it is not generally accepted? Where can you take it?

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".

>If you use stored procedures, you can now serve data up to anything that can latch onto SQL Server - via ADO, ODBC, etc...

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

>Do I believe in VS.NET? For me, the jury is still out....

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?

>What they really mean is that they use VFP because it is the only tool they know.

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.

>I think it is because whether you realize it or not, you are limiting your potential and are boxing yourself in a corner. In effect, you must balance two things:
>
>1. The short term and the needs of the current project.
>2. The long term and the needs of your career and well-being.

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.

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.

>Sad to say but the best days of Fox are long gone.

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. :-)