Hi Pertti,

better you than me. <s>

Doing it in Web Connection with our VPM Web Object (with Web Connection you integrate it right into the Process class, rather than call it as a COM object) would sure be one heck of a lot faster.

Hank

>Aaron and Hank:
>
>There have been many false starts on .NET data dictonary, as you well know <g>. I think the main reason for this is that the .NET framework doesn't provide any good "native" hooks for something like that, at least as far as I am aware. So, for a .NET data dictionary to happen, a developer or a group of developers would need to devote a whole lot of time and resources to create the underlying .NET plumbing for it. It can be done, but it is hard to find the time and resources for an undertaking that could be rendered void by the next .NET update. It sure would be helpful to at least have an idea where .NET is going in this area, if anywhere.
>
>Nevertheless, having been spoiled by VFP frameworks (specifically xCase/xCase2VPM/VPME combination in my case), it is almost impossible to go back a few decades and do things the way they were done back then (read: labor intensive). IMO .NET is not nearly the data oriented language that VFP is, and while it certainly is powerful and well thought out, lacking "data centricity" is a major drawback in my book. Most of this could be achieved by a persistence layer, as Hank calls it, or DBC, as VFP calls it. Something that sits between the database backend and the .NET front end and tells .NET how things are to be formatted, sized, validated, masked, provided with lookups/quickfills, "tooltipped", related, etc. etc. etc. As it is, we now have to do it all by hand with .NET, over and over again. For example, if you need to change phone number formatting from the American style to the European one, you can't just simply change the formatting once in the phone number "domain" of your Case
> tool and have it propagate automatically across ALL phone numbers in your ENTIRE application (regardless of how the phone number is stored in the backend). You COULD create a base phone number textbox class and twidle with it, of course, but that seems so very static compared to the way you can do it with an active data dictonary -- DD lets you (or even the end-user) change properties on-the-fly by "data driving" the application, rather than use a config file of some sort or, God forbid, recompile the entire app.
>
>A database design tool like xCase can handle all of this and then some, and if it could talk to the .NET persistence layer (most likely through XML), now THAT would be a major boost for ANY data centric .NET development.
>
>Case study(let): I currently have a client that is starting to create a large .NET system. They are coming from the VFP world (as am I), and I find myself saying over and over again "no, you can't do that with .NET, we'll have to build our own builders and interfaces for that", when they ask about this or that function or feature that they have been used to getting for granted, out of the box. They are the ones who wanted to go the .NET way, so at least THAT wasn't my decision. But I think they will end up paying an unnecessarily high price for doing what they need to do with .NET, because of the sore lack of data centric tools. Probably the only thing keeping them from doing this project with VFP is the fact that it has to be a web app, and they don't want to base it on VFP + third party web tools, because of the (perceived) uncertainty of the VFP future.
>
>That's my .02 Euros on this topic -- which certainly buys more than .02 US $ these days...
>
>Speaking of which, have a nice holiday, Aaron...
>
>
>Pertti
>
>