Rick,

>>I'm not interested in those features as they can be done in VFP also, though you have to use a variaty of functions.

>Well, there's your answer Walter! You're not interested. I can't blame you but it hardly makes for a balanced discussion on that account...

With all honesty I don't see this. I don't have use for flexible type checking at runtime. I don't see how this alters the discussion. It may help if you drew an example when to use these features and how this compares to the VFP situation. But until now I cannot see the relevance of your argument.

>There's nothing wrong with this. If you want to stick with VFP at all costs, that's great. If you can make money with it and you have apps that run with it great. I have a number of tools and applications internal and built for others that run just fine with VFP and I'm not going to change that either.

That is not what I wanted to say. Of course there is lots of (natural) resistance to jump another programming language which all have to do with very real issues as time and uncertainty which are very hard to measure for anyone. However, even when you're considering switching to .NET, you've got to realize that you'll leave the luxury of a local database engine behind that handling data is substantially different in many ways. You've got to analyze this for yourself if this is something you're willing to give up.

>You talk a bout data munging, but you have to realize that there are other ways to do this. Munging is not something you should have to do with a clean data model or a sensitive business layer. Talk to any DB Admin and they're going to show you ways that you likely didn't realize that you can do those things from the database level without having to do 'post-processing'.

Two remarks:

1. A database server should in its essense not be missused for such tasks. Datamunging can be very resource consuming and therefore should not take place on any database server. It greatly increases the risks of performance problems. I know a few DBA's that have to deal with those situation about every day, so this certainly is not a non issue. A database server is ment to get your data in its raw form (just as a file server is getting your raw file). Datamunging actions are far more better left at the client, *IF* the client if capable of handling that.

2. SQL servers are not that suitable for datamunging actions as their DML which is mainly set oriented generally is not properly equiped for that task. In generall they lack record oriented functions to effectively process data record by record. YUKON, is going to change that as it allows .NET code integration, but it is highly the question if this is good move. The SQL server is going to be poisoned with tasks that do not belong there. It is my strong believe that this development of loading stuff on the SQL server never would happen if each and every client tool was capable of munging local data.

>There's more than one way to skin a cat. I haven't used the DML in Fox heavily for years - almost entirely used SQL. Making the jump to a SQL backend then is a trivial step and using any other data access mechanism as well. You shouldn't have to munge anything with a decent data model to start with.

Well that might be good for you, but I don't see any reason to avoids FOX DML on cursors (views) as it won't have any effect on upgrading to SQL server since you only upgrade the views instead of the cursors handling. This practise has great value to me as I can do this both on local and remote data. FOXs DML handling (I assume xBase DML) belongs on the client anyways.

>>From a theorectical point view, I object against the object solution, as IMO data should be handled relation, not by iterating through object for datamunging. Esspecially If you want to do advanced data munging with e.g SQL commands on local data (thus after you've downloaded the stuff), you're having big problems with ADO.NET in its current state. In the DB world there is a common consensus that data should be handled relational, not OO. Application might be written OO, but the data should be handled relational. Virtually all data is relation, OO database did not make it in the 21st century. I object in getting and setting my data in an OO way by handling collections. This not only from a practical standpoint, but also from a idealogical one. We have a standard when handling relational data and that is SQL. If other DML technologies are supported, fine, but at least give me a reasonable extended set of SQL.

>Well, again that's your view of the world. The model may very well be relational, but the way you want to talk to data is through business entities not through a low level data access mecahnism. Somewhere the rubber meets the road and this IMHO should be in the business layer where you will have that interface between objects and relational data.

I'm not going to argue that this is my view on the world of handling data, but it is not my personal view only. Hereby I'm refering to the world of DB specialist who more or less say the same in articles and lectures.

I don't care at what level the rubber meets the road. The DML has to fit somewhere. If the DML commands are written they should at least not avoid SQL because it is not possible. There are numerous problems in handling data in a OO way.

1. It is a 3GL solution to a 4 GL problem. in a 4 GL you more specify what you want rather than how this is implemented.

2. Iterating through collections is far less readable than a few solid SQL or xBase commands. Though I admit that setting up a good object model with usefull method naming ease the pain a bit.

3. As a result of 2 writing bugfree code is much harder to do.

4. As a result of 2 and 3, readability is much harder also.

Of course the fact that .NET is equiped with methods that ease pain, it is far from sufficient. IMO it has not reached the level (yet) that you comfortable can about everything you could do comfortably with VFPs local cursor.

>VFP's cursor engine is just another abstraction. ADO.NET's object model is another.

>>If you do a lot of SEEK(), KEYMATCH(), SCAN FOR WHILE, LOCATE FOR WHILE, REPLACE FOR WHILE, SET ORDER, INDEX ON, SQL SELECT, etc you've got to find workarrounds for that. You have to build your own classes which are certainly slower than the VFP equivalent because in VFP it is just one command. Granted there are different ways to skin the cat, but my first goal for these internal data intensive task is always performance.

>I personally have not used native commands like that in a while. I mostly use SQL in Fox. Most of the others are supported in one form or another with commands on DataTables in ADO.Net and you can certainly loop and filter thorugh data easily enough. THese are not workarounds this is built-in. It works differently but it's there... Again it's that assumption that VFP has some magical functionality that isn't available anywhere else, which is not correct.

I know looping and filtering is possible. But how about SETting an index ORDER and drilling down the index with a SCAN FOR WHILE . These kind of DML commands are just the DML commands I just so highly appriciate, because those are the fine building blocks that are key to success in data munging. And yes, I'm talking about cursors and views, not DBFs specificly.

I guess you're working with data on another level than I do and have different requirements. If you do SQL only and only basic filtering and scanning I guess you can't go wrong with ADO.NET.

>>It is my strong believe that in a number of cases where performance of advanced datamunging is an issue .NET is not going to be your first choice. I clearly see advantages in VFPs strategy of handling data.

>Based on what do you believe? Have you tried?

As I said above, ADO.NET is missing some advance datamunging DML that is neccesary to accomplish this. I might be that with FOX I'm trying to get everything out of the database engine. I have very high requirements of a local database engine. See the commands above. ADO.NET does not live up to this expectation.

>My experience has been that some things are slower some are faster and for a typical UI based application data performance on its own is not slow at all. There are a number of system related issues (WinForms UI especially) that have inherent slowness, but the data engine for typcial data access has never been issue in terms of performance. For my Web apps where I can easily instrument performance I see data performance at least on par if not better than VFP from a pure performance POV.

I remember you saying different things about the ADO.NET esspecially when it comes to size ( which we did not discuss here). However, it comes down to the point what kind of data access you do. A simple SQL statement and displaying the results is not going to be the problem. Advanced report generation and heavy data munging is another. For example I would not try to handle a 'shortest path' problem in ADO.NET as the size of the data along with the record oriented approach of the problem is not something ADO.NET can efficiently handle.

>>Are you talking about Longhorn? or the release after? Well if I'm correct the future of the Windows OS is that it is build on database technology. When I try to search on my c-drive for a specific file I everytime think that it would be truly an inprovement if the filesystem was based on database technology. And this is just a very simple example. There are lots more that makes you wonder why the hell displaying a simple list is taking up so much time (Display all installed software comes in mind).

>From what's been shown of Longhorn it's clear that Microsoft is planning on exposing everything through .Net apis (WinFs). THe extensibility of the file system will happen through .Net structures only.

>What happens underneath the wrappers and what's exposed are two different things. Supposedly much of WinFs file system is based on Sql Server. This is an example of how an object based interface is exposed on a relational interface...

You've got to realize that the WinFs system is a application on top of database (SQL) server. So this entirely meets the criteria that the data should be handled relational. What goes on in the WinFs system internally is a different matter. It won't surprise me if that is not going to be handled with ADO.NET, but some other technology.

As a sidenote. It would be truly awsome if the data stored in the database server is normally accessable as a relational database or else we revert back to the same solutions in office:

Example:
I want to get all my appointments in outlook between now and next week, filtered from 9 to 5.

In outlook you've got wade through methods and collections and write a page of code to get your data.

If you could access the data in a relation way you could do simply:

SELECT * FROM Outlook_appointments WHERE Appdate BETWEEN DATE() AND DATE()+7 AND ;
        TIME BETWEEN " 9:00" AND "17:00"

Would this not make more sense ?


>>If you extend this to development tools you can't argue that VFP itself also is build on database technology. Forms, Classlibraries, Reports, the project Manager is build on database technology. This is one of the reasons why VFP I find VFP so great. I don't know about the internals of .NET, but I wonder if this is the case up there. I've got the impression that .NET has a long way to go before meeting that goal.

>This is not something I would call a bonus. I've built many tools to read and write these structures and it's a PITA, because in a lot of ways those formats are hacks. They work and we may pride ourselves in having figured out those hacks so that we can work within the confines of them. But that doesn't mean that this is good design or productive to use for developers and certainly not something that hte casual developer would access.

You've got to make a distinction between the developers API and the internal way of VFP running the resources. I too have spend many many hours in digging into these resource. Some things are easy, some things are more difficult and there are definitely things I did not care to figure out. If there existed a component that puts a layer on top of these resources this argument would loose its value. We only have to ask the VFP team ;-).

However the concept of which VFP largely uses is that the program itself is a database. VFP's executables unlike many other types are build up out of a small programm that loads the runtime libraries and run a database intepreter that reads the rest of the data in the executable. This is a concept found in many ERP solutions also and in theory is very, very flexible and powerfull. However, VFP is lacking some feature to use this theoretical advantage to its full extend. I've requested some of those features in the wishlist but they're controlversial if you don't realize what you can do with it.

For example it would not be difficult to make just a database in which all class libraries, reports and forms are loaded (we've got invent somthing effective for programs through) which is sitting on the server. The executable is just reading from the server and running the resources in the same way as it does now. However, this create the possibility to do maintenance online as you can modify forms, classes and resources while everybody is running the application. If a form is changed, they only have to restart the form to take effect. Odd ? Not at all, Navision Financials and its succesors work the same way.

This is not very difficult to do with the current VFP implementation. There only need be some minor changes in the way that the resources are loaded and cached and this already can become reality.

>It's real easy to get set in one's ways and thinking. I'm no exception to this. I had a REAL hard time making the initial move to .Net because I love VFP and have used it for so many years that it comes naturally. You come to see things in a specific mindset because that's how you know to do things most efficiently.

I'm not going to disagree with that. However I'm ignorant engouh to think that I look far beyond that point. I do appriciate your thoughts and thinkings, I do read other articles of .NET and I read MSDN samples and I do read how microsoft positions .NET. However this does not neccesarely change my mind of what the ideal development tool is. It is one that allows to create highly data driven applications. Well I do realize that they are found in the large ERP/ERM world, but I'd like to see that break trough in the normal 4GL world.

>There's no right or wrong. THere's no doubt that there are things still missing in .Net. But there are also many things in .Net that are clearly superior (especially on the Web end of things).

Not a word from me. I'm not developing for the web, so I have absolutely not any doubts that if you say so, It is something no to be ignored.

Walter,