Kevin,

>1. .NET is not a data-centric language, but rather a general purpose development platform
>9. .NET is not based on database technology. VFP is more geared towards that.

>Very misleading. .NET provides data providers and the necessary integration with back-ends like SQL Server, to call stored procs where most of the data crunching should be done. I just spent a day designing some stored procs to process data, where a few years ago I would have brought back data and done the 'data munging' locally. Much of what is done locally can be done in the back-end.

There is a big difference in supporting database technology and beeing based on database technology. For example WinFS was designed to be based on database technology. Longhorn was to be based on database technology. VFP is largely based on database technology (as many resource like forms, reports and classes run on the local database engine). Take the database technology out of VFP and you're left with PRGs. Take out database technology off .NET and you'll only miss ADO.NET.

Look at ERP/ERM solutions. they literally run on database technology. All resources there are stored into a database and run from there.

The discussion whether data munging should be done locally or remotely is a very different one and has nothing to do with the statement.

>2. You have very limited ways of working with a DML locally (with ADO.NET): You'll have to do most of your data stuff remotely.

>Again, for the folks who build their stored procs, this generally isn't a big issue. See additional comments below.

It might not be a big issue, or it might be a big issue. SQL is a set based DML and not record based. If you're doing datamunging for example for the purpose of graphing where you often have to transform normalized data into non - normalized data and have to insert intermediate records for graphing (e.g. crystal reports) a record oriented approach is much easier.

And of course there is an issue of loading to much stuff onto the SQL server that really does not belong there in the first place. Writing numerous stored procedures on the server IMO often is a kludge o matic way of solving problems that should not exist in the first place.

>3. Data binding is not as easy as in VFP.

>Out of the box, I concede this point, but the shortcomings are not insurmountable. If one is interested, one can build a few generic classes and a binding interface to make future projects easier. If one uses the Mere Mortals Framework, one is further insulated from this issue. Yes, the next version of .NET is suppose to improve this.

>However, prior posts have been misinformed on .NET's binding capabilities. Somewhere along the line, there was a belief that datagrids were slow when loaded with a table with thousands of rows. This just isn't true - a datagrid can be bound to a result set, so it generally loads in about the same amount of time if it's 5 rows or 5,000 rows. The fact that this was claimed without verification speaks to the issue I raised a few nights ago about accountability.

However this is not the whole story Kevin, Aside from a note I found that when binding to a datagrid the recordset is going to be validated in its entirety (which I really cannot check), there is definately an issue when wanting to presenting something else than the first record in the grid. A general accepted method with large recordsets is using paging, but that has a side effect that the record set is run through from the beginning for each page change. So with large sets it is going through the top to the point you want to display. There have been reports that beeing a performance problem. Whether that is significant in general I leave up to you, but this definately is a architectual difference from the way VFP handles grids.

>5. .NET generally is more low-level, meaning you generally need more .NET code to do the same as in VFP.

>If one thinks along the lines of building a set of template classes to accomodate certain tasks, future project endeavors may find the actual ratio isn't as high as you'd think. This statement carries less and less weight as one becomes more experienced with the tool.

Look you could do the same with C++, but it takes time to build those classes and generally the problem is that the solutions you build are not compatible with solutions another builds. The solutions one builds tends to be geared towards the problems you encounter but not towards the core of the problem. Way better would be that it was delivered out of the box where you are ensured everyone works with the same solution and you can train people wioth the same solution. It really does not make sense to do this on an indidual basis as everyone is trying to reivent the wheel and there really is not general .NET documentation to handle this efficiently.

> A .NET newbee tries to port his VFP application into .NET and does not realize that you should only download the data you need via a SQL command through ADO.NET in stead of USE Mytable and THISFORM.Grid.RecordSource = Mytable. This person might conclude that .NET cannot handle lots of data and present this as fact.

>I've heard this before from you, and it's a highly specious argument. If this conclusion is indeed initially drawn, it's far more reflective of the person's lack of exposure/experience in remote/distributed architectures. But even for 'desktop/LAN' apps, a simple business object with a few table properties and a getdata() method takes care of this. Sadly, this isn't the only perceived shortcoming that has been presented as fact. Bottom line: this is as close to a non-issue as it gets.

You'd be surprised of how many facts are fabricated this way.

>A .NET developer might succeed convert his 'Tastrade' level application from VFP to .NET thereby concluding that it is easy to port YOUR application to .NET.

>Please provide a specific instance where someone converted an app identified as 'Tastrade' level complexity, and then concluded that it was easy to port other apps.

Note that these were examples, though I've got the idea that from certain individuals they were drawing this conclusion. The point is that it might be easy to port a 'Tastrade level' application into .NET, but it is about impossible to create a data database driven ERP/ERM applications like BAAN, SAP, NAVISION into .NET. And there are a lot of gray shades between the two. Note that I'm implying that VFP is somewhere between the two.

> Use sophisticated DML, (such as SQL, REPLACE ALL, SEEK, etc) on data that somehow got into the client. You'll have to program this functionality yourself.

>ADO.NET has an equivalent of SEEK.

You can only seek on the PK which is the only indexed entity. Seeking records on other fields, maybe in conbination with descending indexes, filters and SET NEAR on is not provided.

>It has the ability to filter result sets. You can code a generic REPLACE ALL function.

Of course you can code it, but there is no standard DML for it. You'll have to code by iterating through the collections. Not even to mention that if you want to use indexing, filtering (FOR or WHILE clause) relations or any other expression in it, you'll have a very hard time to code a full VFP REPLACE command.

>One can accomplish many of these things in ADO.NET. They are just done 'differently'.

No, .NET requires them to be done differently...

>In many instances, with more lines of code?...yes. Can you do 'everything' in ADO.NET that you can do with Fox cursors? No...but I've come to realize just how much should be done in the back-end to begin with. I don't believe that entirely validates the criticisms that have been leveled against ADO.NET.

Well I do, I'm resisting to the mechanism of loading the SQL server with this kind of rubbish. In VFP you have a choice. Process it locally or on the SQL server. You can make a strategic decision here. In .NET you don't have much of a choice.

>Walter, I'm sorry, I'm really trying to avoid escalating this to a heated level, but these types of posts just don't offer a quality and substantive analysis of the tool. Yes, .NET has issues (just like Fox has issues) that will hopefully be resolved in the next issue, no question. Those who have used .NET can offer better arguments about the deficiencies of .NET than the ones presented here. Why? Because they dove into it, and built applications with it. But it is still a powerful development tool that can be used to provide business solutions.

It is not a heated discussion IMO (if you're use to talk to JVP). And yes, talk to John Ryan. He's not saying much different than me.

Anyways you responded to my list of facts. In so far you did not reject the list of facts. All you did marginalize the consequences of the facts.

Walter,