Hi Rick,

>>So my experience says that for every application I'll have to define application specific classes, not beeing part of a framework. Within those classes, I'll use many complex functions out of the box without using a bridge to a framework class for many functions, just because they already well abstracted. This will mean that when going to do .NET development I'll try to implements VFPs DML functions into a classlib. When this is done, I totally agree, the amount of coding for every new system is not going to be much different from VFP. However, note that building such classlib with the same functionality of VFPs DML is a trivial and tremendous complex and difficult task.

>If you ask to work that way. Most .NET developers wouldn't want to do things the FoxPro way.

>If you do - then why would you even consider going to .NET (which you are not of course)? If you want to work 'like VFP', why not just work WITH VFP? <g>

That is not entirely true. We are truly considering .NET for our internet extensions, in fact we have already decided that this is the way to go. However for the desktop apps it truly is a different story.

>As I said before, if you approach .NET from the Fox perspective and want to make things work just like Fox you will be immensely frustrated. While the Fox was works great, it's not the only way to do things in terms of data access or otherwise. And if doing thing the Fox way is so important - well VFP is your answer.

I think I know quite a bit about data. And what I see here (And this has been acknoledged by a few MS representatives as well), is that (local) data access is truly undervalued.

>>Of course a much simpler path is to define a data handling strategy into a data layer which is much more simple and straightforward to implement, but then you're losing the granularity and flexibility of the VFP functions. And its funny that just the argument of granularity is used often in favour if .NET. When it comes to handling data, it seems a .NET implementation is either too granular (Do everything yourself again and again and again, like iterating and munging through ADO.NET collections)or not granular enough (Define the interface of a data layer and using business objects to handle the data related tasks). Well I'm sure it just a matter of time when granular functions that have an equivalent into the relational world of data (Like the SQL or XBase DML standard) becomes available, but until that day comes, it is clearly a disadvantage of the .NET framework.

>The difference is an object based approach to data vs. a record base approach to data.

If I take a theorectical stance here, I can blow these arguments to pieces. The object based approach sucks big time in many ways and therefore is far inferiour to the relational (the term record based is misplaced here) approach.

First of all, there is no standardized DML available. No SQL, No xBase. If I look at MS outlook with a COM interface where the data is accessible through objects and collections. Why do you think it is so cumbersome to get all the email from a particular sender, the 10 most recent contacts entered. The appointments of today ?? Why do I have to spend a few hours or even a day to program this stuff, why not something like ?

LOCAL oOutlook as Outlook.application, cXml as string

cXml = oOutlook.GetData("SELECT * FROM eMail WHERE sender = 'Tax@Tref.nl'")
cXml = oOutlook.getData("SELECT TOP 10 * FROM contacts ORDER BY TimeEntered DESC")
cXml = oOutlook.GetData("SELECT * FROM Appointments WHERE AppDate = GETDATE()")

Outlook is the perfect example of a terrible way to handle data. It is dreadfull slow and very cumbersum to get your data out. For each analisys to be done on object collections you'll have to write your own classes and functions. It is cumbersome, buggy and actually a waste of time and resources. It can be done far more efficient if the data is handled relational. IMO, data should be handled relational, whether it is on a client or server: it does not matter. This means transparancy and scalability

So could you give me a reason to revert to a technology that handles data and throws me back at least 25 years ??

Second, Objects and collections do take process memory. Therefore ADO.NET has a scalability issue when dealing with larger amounts of data on the client (Have you ever wondered why outlook takes 3 minutes before becomming responsive when your pst file is taking half a gig)? Yag is working on making this scalable in future .NET versions, but the only way to do that, is to define a file format so that ADO.NET recordsets can be flushed to disk and not taking up process memory. My question to him was why to stop there? You could define a full spec database engine a'la VFP to solve a lot of issues surrounding data.

>Using Collection is not only logical it's also easy. Whether you use SCAN or a FOREACH loop to iterate through data is that really so much of a difference?

See arguments above. Collections are a PITA and should never be used to handle larger amounts of data. Relational is the way to go. The application should be OO, the data should be relational.

As for the difference between SCAN and ForEach. That might be true when you do a simple SCAN. LOCATE FOR WHILE is already a bit more work. REPLACE FOR WHILE even more programming. A simple SELECT ... FROM MyLocalCursor1 INNER JOIN MyLocalCursor WHERE GROUP BY is a real nightmare. .NET has only one answer and that is to let the database server do those actions. But sorry that is no answer to me.

>You're stuck in the VFP mindset. This is neither wrong nor bad, but that's clearly what the issue is. Nothing is going to satisfy you unless it matches your VFP user experience... it'll be a long time if ever before alternatives

I don't I'm stuck in the VFP mindset at all. I'm stuck in the data mindset. If VFP development stops I probably end up in doing ERM/ERP, business inteligence, information analysis and exchange, where working with data is far more advanced that muddling arround in .NET. Of course you don't have the great flexibility on a low level, but at least you have the tools that efficiently can handle data in a (semi) relational matter efficiently. Again, My mindset is set to data, not in total control on the low level.

The issue seems to be that the .NET guys for whatever reason cannot / don't want to see, that handling data is a huge step backward in .NET. They fail to see how this fits in the evolution of software at all, missing the the lessons told by date and codd what it means to handle data relationally. They fail to see why OO databases failed. Why SQL (while an imperfect implementation of the relational model) is so important when handling data. They miss the theory and the vision how relational data and OO developed software should be integrated (again see outlook example above).

While VFP is growing old, and surely many things could have done better when they started from scratch now, it at least recognizes the need for such architecture. It might explain why xBase has such a long life. Just disregarding this issue is just plain ignorance if you ask me.

Walter,