Kevin,

>Because I was acknowledged that in that situation, I was being provocative. Some people SHOULD be provoked/challenged into learning more about a technology before jumping to conclusions.
>
>I wasn't referring specifically to auto-spanning. I had started a new sentence, but I can see how someone would have thought I was lumping the two together. Yes, auto-spanning would be nice. I'm talking about many other things with ADO that many aren't aware can be done.

Beeing one participant early in the game outlining the differences and the shortcomming of .NET, I could only say that the .NET embracers did a very poor job in objectively describing advantages and disadvantages between the ADO.NET and VFPs data engine solution. I can't remember one disadvantages beeing mentioned by those .NET embracers.

In fact JVP went so far in plainly saying "There are no disadvantages". Now since I believe in the phrase "Every disadvantage has its advantages", I clearly felt the facts arround ADO.NET were propaganda and nothing more than that.

Jumping to conclusions on this actually was fairly simple though. One thing that was pretty obvious is that ADO.NET is not a local database engine and does not embrace any standardized and transparent data manipulation language. Therefore it is less scalable and narrows the flexibility you have in solving data related problems. Skill learned from any other tool dealing with releational data are worthless.

Taking the helicopter view, you could see fairly easy that ADO.NET was not designed for data manipulation on the local data, and never will be because it design is just wrong from the start (And I can tell you that MS will prove my point in time). In stead of seperating data from the programming language it is far more tightly bound to it than in VFP. An example of this are :
- The hoops you have to jumps through in respect of strict data typing
- Regarding relational data as scalar memory objects and therefore cursors are not flushed to disk.
- It totally ignores the standard of SQL or xBase to get at your data. Despite the fact that there are method and properties to handle data far easier than in its prior versions, it in many cases leave you up to array iterations. Instead it has its self invented (though it probably borrowed some technology from JAVA).
- No support for multiple level local data transactions.

Relational data and algorithms are just two different animals that should be handled differently. A lesson that has been learned a long time ago and is proven in ERP/ERM/CRM enteprise systems. It is not a shame that .NET does not support it, because that was not an objective from the start.

Even before actually touched .NET in any way, you'd not had to be einstein to see that .NET really is not a data centric development platform a'la VFP. OTOH, it never was intended to be. It surely carried some improvements, but MS realized way later that the data handling part of .NET was some underdevelopped point of .NET, directly proven the point some of us, including myself, have pointed out way earlier.

You yourself actually knows what happened, when I addressed those points. The .NET crowed denied high and low that my point were valid. I've only seen rick strahl openly critisizing .NET for its data handling capabilities. I'll take that no-one of those .NET crowed used VFP to the level where VFP strenghts are. Sure if you only use VFP in the same manner as you used VB, then there is no problem. OTOH, you never learned what the strenghts of VFP are.

Is this to say that VFP is perfect? No it certainly is not. There are a lot of short commings and design mistakes. If I was faced the task to redesign VFP, it would have some significant changes end enhancements. A few examples:

- LAST() and FIRST() functions in SQL SELECT to pick the last or first value in a specific order (in fact this should be adopted by the SQL standard)
- GETMIN(), GETMAX() functions in SQL SELECT with the same function as the VFP MIN() and MAX() functions which have a total different function in SQL Select.
- Better optimizer by handling complex OR conditions the same way as unions so that the UNION and OR equivalents use the same optimizing algorithms.
- Use a better way to distinguish fields form memory variables. (Using the e.g {} characters: e.g {MyTable.MyField})
- An alias of a table should be an object (just as in ADO.NET) in which you can set and retrieve properties in stead of using some obscure CURSORSETPROP.
- A function to allow to return an alias.
- Simular to above, database definitions should done reachable though an object model (additional to the SQL syntax)
- Optional strict type checking as you type and compile (note that strict typing under runtime still is not supported).
- Passing an alias (since it now is an objec) by value (Passing by refference would create difficult to solve conflicts) through to other datasession and through the boundaries of COM
- Better grids (subject on its own)
- Every xBase command allowing for an IN (alias) clause (e.g LOCATE).
- TABLEUPDATE [FOR cCondiction] [WHILE cCondition] [WITH FORCE] [WITH ERRORREPORT aArray]
- TABLEREVENT [FOR cCondiction] [WHILE cCondition] [WITH FORCE] [WITH ERRORREPORT aArray]
- Having remote views with support for macros ?&cWhere
- Ability to create an local view out of cursor in the same way as you can do with a SPT cursor
- A PUTAUDIT([cFields], [cPk], [cTable], [cUser]) and GETAUDIT([cField], [cPk], [cTable], [cUser]) function, which stores record contents in a uniform way into an audit table. Not we cannot do it today, but it would come out of the box
- Get all those SETtings in an object model bound to the sessionID. Private session inherit from the default but could be overwritten with properties)



Walter,