Walter

>HI kevin,
>
>>>>My view on this situation has always been the same, MS are going to butter-up the Fox community with some great updates, not just normal updates, but ones that bring you closer to the features that are available in VB and C#, I still think that a lot of Fox developers are being lead down a path leading to one place only - .Net.
>>>
>>>As long as .NET does not offer use a fast set and record oriented local data engine to process results from SQL-server, and process internal META data, .NET has nothing to offer for a real profesional VFP developer.
>>>
>>>Many people jumping .NET seem to forget this.....
>
>>Like I said previously, it depends what type of app you are developing, and to what scale.
>
>I'm sure it does. However, I think large data driven applications need a local data engine.

I'm not sure what you mean here by "need a local data engine"?

>>Having a native data-engine is not always a good thing, ever tried writing a 3-tier app in VFP and binding front-end objects to business-objects? It's like trying to get blood out of a stone.
>
>I do not see why such mechanism has to do with a data engine. XML should be the glue of the tiers in here. Personally I don't see much value of a n-tier system if the from end is purely a VFP GUI. I'd rather make the second tier a layer which runs on the same machine (if possible).

What I mean is, Foxro has been designed in such a manner that when you take away it's native data-engine and try to replace this with objects, it takes some time to get it to work, so much so that throwing the towel in seems a good option.

>
>
>>THe less you bind your applications to the live-data, the more scalable it becomes, VFP, like Access, is holding people back from this IMO, it invites you to directly bind data into controls. When have been writing an app for over 4 years, which I have, that eventually leads you into some serious sh*t, and that's talking from experience, I now despise the idea of binding controls to live-data, it has made a very complex application even more comples, less maintainable and impossible to interrogate.
>
>I think its is not a matter of live data (though I might have a different opinion here than you), but about processing data from either DBFs or just cursor whether they origin from a DBF files on the network or somewhere compiled in the executable.

Sorry, I don't quite follow what you mean there.

Kev