Kevin,

Of course you know my standpoint, but for the lurkers it might be of any use.

>It does work both ways in that people who choose to let .NET mature before jumping in are not po-dunkers either.

>I'll ask a question that I believe I asked up here some time ago - how are you measuring 'when .NET matures'? Why specifically do you believe it is not stable? I continue to believe this is more a stall tactic. While some wait for .NET to 'mature', others are building some pretty sophisticated apps with it.

.NET still has a lot of maturing to do on the data side. Data binding is one of them and a far more powerfull way to handle data is IMO one of the big innovations that have to happen before I'll port any of my data driven applications.

The announcements of data improvements in next releases of VS.NET backs up my standpoint. The problem with the previous and current release is that though it provides good programming support for pure algorithms, it is lacking real powerfull data handling possibilities.

Every program is both about data and algorithms. Today there no one tool available that has the best of both world. VFP is lacking many of the benefits of .NET, but .NET is lacking many of the powerfull data handling capabilities VFP has to offer.

Now, with all the announcements about more data centric functionality beeing implemented in .NET I do recognize that .NET has the best cards for the future. However to jump ship right now might be unwise given the fact you cannot USE those newly announce features yet. So what does this mean? Working arround the data centric problems currently and rewrite them when they are going to be available is not my idea of beeing productive.


But there is more for a structual problem also. Surely I've expressed my dissapointment on the absense of a local dataengine in .NET. One thing that I highly appreciate is the fact that most resource in VFP are based on tables (Classes, Forms and Reports). And this gives you a very powerfull tool to development. An example.

Suddenly I needed each and every grid in my project to have a unique objectID as I wanted to store the column positions, width and rowheights of each grid in the project. What I ended up doing is adding an objectID to the baseclass and opening each and every form and classlib, searching for this class (and subclasses) beeing used and inserting a new line in the properties field giving the ObjectID a unique ID (with a Newkey generator).

This algorithm was no longer than about 15 lines of code and took about 5 minutes to write, and about 20 seconds to execute. I'm not sure there is a way to do this as efficient in .NET, but this I find a very valuable VFP feature.

Another example is to write some data mungine routine that constructs a report (rpt) file at runtime and after that executes the report.

How about changing a used class class on every form or class from classx to classy?


Now to explain where I'm comming from.

I learned that an application is build up out of two main components: Algortithms and data. Each language should provide suffient means to both program algorithms and handle data.

I was trained as a software engineer with a specialty on relational databases. One of the important rules both CODD and DATE made up was that the database definition should be stored in normal tables so they could be queried and manipulated in the same way as normal tables, making a very transparent and flexible database. AFAIK, most (R)DBMS have followed this rule.

I also learned that large amounts of data should at the least be handled relational, so again in your application you could use the same DML you use on databases on data in your application. In VFP this is nicely implemented as you can have local cursors you could, create, insert data and query upon in the vary same way you could query upon remote data. In .NET this sadly is not available yet (SQL DML) until they implement a local data engine object that is able to handle data in the same way.

I'm convinced that the future of development is about storing everything into a database, whether it are classes, resources (like icons, bmps, menus), forms, reports, etc,

Just think about it:
- Source control would be much and much easier (you can use the transaction log for reverting in time)
- You can use a DML (SQL) to manupulate and query upon your projects source.
- All your programs resource are in one database, no cluttering up you HD with tenths of thousands of little program files.
- Compilation is a snap as it really is a collection of all source tables + one execution header.
- Working with three programmers technically is not more difficult than three users operating on one database

Many of the ERP/ERM solutions follow this principle.

When looking from this side, VFP is more close to the ultimate solution than .NET is. And this is really one thing I'd like to see .NET mature on, otherwise .NET will be exit within a few years and succeeded with a more ERM/ERP solution. MS already has the technology, they only have to put it together.

Anyways, this is my view of how application development should look like, and sadly .NET currently is far off despite the technical improvements and advantage over other languages.

This does not mean there is not a lot to complain about when it comes to current ERP/ERM solutions and VFPs implementation. Sure integration with other technologies, general acceptance, pricing, marketing, performance, language, nice orientation have always been a problem (and will be in the near future if MS does not go this way).

The future will tell if I'm right.

Walter,