>>>Thanks for your replies, the one thing I was still curious about - if any of the apps from your company had used .NET and typed datasets in an application.
>>
>>No, and I'm not sure why you think it matters given my reasoning behind it:
>>
>>I'm not driving a truck, but a normal car because it is the most practical vehicle to me. You're trying to say: How would you know that a truck is impractical since you have never driven in one? I'm not the type of guy that will drive dozens of different vehicles to see what is suiting me best. Just like any normal person I sit down and look at the pro's and con's of the vehicles and make a choice. Only then I'll take it to a testdrive to see what is most confortable to me. Why would it be any different in selecting a ORM solution?
>>
>
>This approach can be very problematic. When someone doesn't use something, voices an opinion on it anyway, and doesn't feel that not working with it should "matter" - it puts one on shaky territory to discuss context. I don't like "car and truck" analogies because they are too simple - but to use it for discussion, you're assuming the person knows the attributes of a truck to begin with. How does one really "know" it's a truck and not something else?
>
>You might think I'm exaggerating, but consider this. There was once a discussion on the VFP grid supposedly being superior to the WinForms datagrid. A web link/blog entry on the shortcomings of the .NET datagrid was offered as proof. The only problem was that the web link was discussing the ASP.NET datagrid and not the Winforms datagrid (which are 2 very different things). The person who provided the link as "proof" had no background, no frame of reference, to detect the most basic of context. So that's why this approach can be very problematic.
>
>One of the most intellectually responsible individuals I've ever known is this regard is Bonnie Berent. She has had a policy for years of never voicing an opinion or a perspective about a technology topic unless she had used it. I don't claim to be perfect in that regard but I think that's something to hold as a standard. (And I know for a fact that she wrote utilities in her work environment to manage typed datasets). If a person doesn't want to use them, if they'd rather use other methods for solving things, fine. We all know there are many ways to solve problems. But criticizing a topic and clutching to the same single argument that they exist to keep the compiler happy, just overlooks too many key points.

Kevin lets leave it at that my vision is not in strict type languages as the ORM part will Always bite you in the but because you have to specific data structures on both the front and the backend while in the end the back end is leading in any way you cut it. What is the overwhelming reason there is a need to specify this twice? In the end the backend is leading, and my developement is geared towards solutions that is as flexible and tolerant on the changes on the backend as possible. Typed datasets simply do not fit in this picture.

I'm not alone in my view, also in the .NET world these questions are being asked. There are proponents to types datasets and ones that would not implement it for the reasons I've mentioned here. That is even besided of technical implecations on large footprints and performance argumentents that are being used in these discussions.

I've read quite a bit of bonnies contributions on the topic, but they come from a perspecitive that IMO is too implementation specific oriented (inmediate benefits for developers, rather than architecture) and has less to do with architectual challenges that apply to large implementation of EMRs, SAAS, SPAAS and other repository development architectures.

So lets leave it at that I have my reasons not to drive a truck because it does not fit into the my mobility picture.