Hi kevin,

>.Net does have in-built data capabilities, local DataSets, DataAdapters etc.etc. I don't believe that the core reason behind .Net was efficiency, that comes later, it was to create a standard of application development that could be used across the board. IMO the less you tie applications into a certain development tool, the better. If you rely on VFP's data capabilities when designing an app, then if 10 years down the line VFP is no longer, you're going to face problems. However, using a standard language like C# is not going to cause you nearly as much problems.

Huh ? I don't follow this. If you don't want to tie an application to a certain development tool, why isn't VFP suitable anyways ? This IMO is nonsense, Certain types of applications call for certain types of development tools. It's ignorant to believe you can build anything in every platform. I'm not going to design a device driver in VFP nor do I want to design a full blown database application into C/C++. I'm not going to implement the fastes prime number cracker in VB nor do I want to create a graphic program using machine code. Every language has its place though its application might get more specific (as it is the case with VFP).

When it comes in handling and munging disconnected datasets on the client VFP is the real champion here.

>C#/VB are (nearly) full-blown OO languages, if you design a pure OO application, you would not be missing the datamunging capabilities of VFP. There are other ways, no they aren't as efficient, but yes they are more scalable and are mroe standard.

I don't see the relation between using a full blown OO language and the data it processes. They should be totally unrelated IMO. They've tried to harmonize OO and relational data, but aside from some experiment with OO databases the most efficient way to handle data is using relational data which might be handled in an OO environment.

To be honest I don't see the the other ways. Data should be handled relational not in a OO way. Not because I say so, but since it is the standard. Handling data in an OO way is asking for all kinds of problems: The same problems which caused OO databases (on a large scale) to fail.

>>If you're trying to this, I think you've got the wrong idea. Working with objects that way is not a wise option anyways (is it with .NET ?). The buisiness objects should pass the data to the front end, which in its turn should represent the data (Strings: CursortoXML, FileToStr() functions). Binding the object data directly to the front end GUI is not a good practise anyways if you'd ask me.

>I think this is down to preference and depends entirely on how the framework is modelled.

As you stated above, handling data in an OO way is not the most efficient. In the case of .NET you might have some tools to help you on this, but nothing beats just the relational approach. As others have tried handling data in a Object oriented way is cumbersome and IMO, certainly not the logical choiche, no matter which environment you're using.

Take for example the Treeview and Listview ActiveX controls. They rely on an object model to store data. Though I can work fine with it, it still is cumbersome to tie your data to it. What if there was a possibility to directly connect your data to a treeview or listview. Would you or would you not agree that this is more efficient.

>No, .Net was built to handle ANY type of application, although there are some great in-built capabilities in VFP, it doesn't make .Net any less capable.

Are you going to build device drivers in .Net? Are you going to build programming languages in .NET (in its current state)? Is .NEt cross platform? Does .Net make C/C++ obsolete? I certainly do not agree with this standpoint. .NET might have a wide range of application, but its definately not a platform which makes all other tools obsolete.

Walter,