>>This is not an attack on .NET, its criticism on strict typing and tools that force you to type for the sole reason to keep the compiler happy. In all fairness, .NET has taken quire a bit of steps to overcome the problems related to what I refer to. At least now (VS4) you can write office automation solutions that work for what ever version of office by using late binding and bypassing the compile time checks (object type), without having to revert to things like reflection. That is good and was needed.

>>However when hearing the word "Typed datasets", I start to shake and shiver.

>Actually, late binding was available for certain office automation tasks a while back.

Yes, but correct me if I'm wrong, the dynamic object datatype was only introduced in VS4. At least now you can write that office automation in with the same ease as you can in VFP (but no intellisense then).


>Where I completely disagree is the argument that typed datasets "only" exist to keep the compiler happy. They have benefits which have been covered many times here. Bonnie Berent was (and I'm guessing still is) a major advocate of them. Cathi Gero also talked about the benefits - I know that for a fact because I worked on a project with her.

You might have a bit of a point here. My gripe with it is not only about the strict typing, but the whole idea behind the typed datasets.
It does not have to be strict typed anyways, as much of those functions can be handled without strict typing (Think of VFP SQL views,,,, yeck, see below)

>I have a question - in the last 10 years, how many different companies have you worked for, and what were the types of team sizes you dealt with. And have you used typed datasets in a production application with other developers.

Kevin, I'm an (co)owner of two software companies (one since 1992 and the other since 2002) and work with a team of developers, support, trainers, domain experts and sales, of which there are at least 3 well known developers here on the forum, but its not up to me to reveil their identity (g). One that I can say, was Jim Nelson, who died a few years ago. We have one flagship, a highly specilised EMR software package that is being used on five continents. We are not talking about a simple mom and pop application here. In fact were are the biggest of its type in the english speaking world and millions of dollars went into the development of it.My team works on the development of the flagship, but also on Industrial interfaces between our software and medical equipement, hospital system communication based opun HL7, patient portals (web, java based) and other technologies. Not at all a VFP only environment

Anyways, Typed datasets carry much much of the problems that local/remote views in VFP did. And oh boy did we have a lot of fun with those. I still remember the day we finally got rid of those by using a cursoradapter approach where the datastructure is much more dynamically determined based opun what is returned from SQL Server.

Yes I understand that typed datasets will give you the benefit of using intellisense, but that does not weigh to the horrors in a large project when datastructures change affecting not only the flagship, but also many external services such as HL7 interfaces, which are running at many clients with difficult access to. There is seldomly a need to change the metadata to create the cursoradapters now, while in the past we needed to update the local/remote view definitions whenever we made changes. One thing we do now is that our database is Always compatible with each previous version of our product. I don't miss the days where I needed to update the datastructures of the views when the database or SQL statements changed.

Now I can create a CursorAdapter by a simple method call:

oDatahandler.CreateView(cSQL, cAlias, cCursorSchema, cUpdateInfo, nBuffering, lNoData)

The cCursorSchema and cUpdateInfo can contain wildcards so that columns that do not need explicit casting (such as datetime to date) do not have to be mentioned explicitly. Lots of other bonusses as well in terms of raising event, validation and audit trails. If the SQL statement contains a SELECT *, nothing needs to be changed if a column is added or its definition changed in order to include the column in the resultset, included in validation, updates and audit trail.

So my aversion to anything strict typed is that the compiler wants to know more than I myself would know at forehand. I'd rather go for a strategy that my software deals with changes on a database in a much more dynamic way. Now of course in VFP you never had intellisense for fields anyways, so I do not miss that, But I certainly do not miss the high maintenance on view definitions.

Now I'm sure you can see where I'm comming from, let me ask you a question: do you think ORM is perfect by using typed datasets? If not, where do you think it falls short?

BTW, I appreciate the fact that we can hold a discussion based upon real arguments.

Walter,