If you paste the URL in (be sure to get all the way past the aspx part) it works correctly.

Perhaps the difference we perceive is that I model in xCase, where what is designed is much more complex than what could be modeled in an object, without jumping through many hoops (and in fact, those kind of complexities are a known shortcoming of ORM's in general). The app I send most of my time on has 522 data tables (and about 30 metadata tables). Modelling that in an ORM would be a nightmare. In xCase, well, that's what the tool is designed to do, make it possible to think clearly about complex data structures.

Anyway, take a look at the MSDN article and see what you think.

Hank

>MSDN gives me a page not found on that link.
>
>I think what I am talking about are entity objects - the idea of modeling a real-world entity without thinking first in terms of tabular, normalized data. Everything we heard in the early VFP 3.0 days about "objects" interacting with each other was fascinating but as soon as one looked at the data structures we saw there was little relation between the theoretical model and the CODD world we grew up in. ( Good night, Jeff Winchell, where ever you are <g>)
>
>All the querying i was ever taught to do in VFP or SQL involved normalized data and pulling queries which temporarily denormalized the data.
>
>But the "impedence" as I understand it involves taking entity object and tabular, normalized data and having them understand each other.
>
>( and I do understand that business objects - at least as I have always used them in VFE - are simply a business layer wrapping some kind of query - not at all what is meant by an entity.)
>
>>Hi Charles,
>>
>>the impetus behind ORM pieces is to be able to address data through objects without having to do all the work of strongly typing each and every field. Other stuff (e.g., carrying metadata along) gets added in, but the problem being solved is the one that any object must know what it is (data type, length, decimals, as appropriate) before it can be created. What you are talking about is business objects, which are another solution to a different problem, and I'm not opening that can of worms at the moment. So no, I don't think we are talking about the same thing. Here's the MSDN article I mentioned: http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx Do you think we are talking about the same thing?
>>
>>Hank
>>
>>>I think we are talking about different things here. As you know, in VFE we always worked with objectified data in the sense that a cursor was an object, including the fields.
>>>
>>>I am talking about the data model itself. When Jim Booth gave his presentations in '95 or so explaining "objects" there would be talk of a "Customer object" etc but that was never explained as it related to normalized tabular data. We just did not organize our data as "objects" which by their nature were denormalized. That's what I believe is meant by the "impedance mismatch" and was certainly the drive behind ORM.
>>>
>>>I don't see where objectifying data as I believe you are describing - and which I think is what I've been doing for ten years in VFP/VFE - addresses that issue at all.
>>>
>>>
>>>>Hi Charles,
>>>>
>>>>if I have to create objects to operate against data, and that requires mapping, I have an impedance mismatch. It's conceptual only given an assumption: that objects are statically typed.
>>>>
>>>>In VFP, I assign a controlsource, and the typing of the fields is done for me, because the fields are not statically typed. This is taken a step farther in the VFP Compiler for .Net, where the cursor itself is entirely an object, including the fields. And there is no mapping required.
>>>>
>>>>The impedance mismatch is, then, conceptual, in the sense that the concept of a statically typed language creates the problem.
>>>>
>>>>Hank
>>>>
>>>>>>Hi Mike,
>>>>>>
>>>>>>indeed. If you read the MSDN overview on the Entity Framework, it talks about solving the "impedance mismatch" (their term) between data and objects. And the MVC framework is yet another attempt at the same thing. Just as Linq was. Just as ADO.Net was. VFP has no impedance mismatch, of course.
>>>>>
>>>>>I assume that is tongue in cheek as you know the "impedance mismatch" has nothing to with language but is rather a question of conceptual modeling. One of the first WTF's I encountered as OOP was explained with VFP 3.0 was that the "objects" that were being described did not map to the normalized relational database model we had grown up on. If that "impedance mismatch" was magically solved by our magic Fox I must have missed the memo <s>
>>>>>
>>>>>And I am sure you know enough about Linq to know it goes way beyond the idea of doing sql select statements against tables to get cursors.