Bonnie,

As it was explained to me, the only performance advantage of using typed data sets is that for value types (bool, char, enums, and all the number and byte types) you can avoid boxing them (casting them to objects) and unboxing them (casting them back to value types) to get them in and out of the database, which you do if you use the regular DataSet class, which stores everything as an object. According to this, then, if you created a typed dataset for a table that contained no value types (only columns that mapped to DateTime and string in C#), you would get no performance benefit at all. Accessing a DataTime or string via a typed dataset performs no better than just casting it from a DataRow indexer in terms of performance (but it is uglier code).

A secondary benefit, of course, is having all the columns exposed as properties in the IDE, which, for me, is a big one, because I otherwise end up looking at tables in Query Analyzer or Enterprise manager to get the column names.

Around here, all our tables are pretty fixed unless we are adding new ones. Column names are never changed and columns are only rarely added. I don't use the designer at all except to initially create the class file. If our table structures changed more, I might miss the XML designer.

Having a typed dataset column property return an object does undo the benefit of a typed data columns,but if that column is nullable and a value type, trying to use the automatically generated property for that column is unsafe and StrongTypingException prone. You can either wrap up property references in try-catch blocks, always check for null using the DataRow indexer before accessing the value, subclass the typed dataset, or change the code in the properties.

The first two options, I would argue, are bad OOP, repeating the same logic everywhere, tempting fate and hoping that no programmer will ever forget. Of subclassing the typed dataset and turning off the code generator, I guess you are right, the best solution depends on your environment.

So how do you handle nullable columns that map to int or bool properties in your typed dataset subclass?

I think that our paradigm works well for what we are doing, but I would like to know what the best solution for your data environment is.

Thanks,

David

>David,
>
>Sorry I never got around to answering your other post. I got busy and then I forgot about it ... this more recent post reminded me that I had yet to answer the other one. I'll kill two birds with one stone. <g>
>
>I have a few problems with the way both you and Jason are handling this:
>
>1) I'm not crazy about "de-automating" (as you call it) the generated typed dataset class. If you need to make more changes to your .xsd, then you've got a lot of copy/pasting to do. I suppose you could automate that easily enough ... but I'd prefer to sub-class the generated Typed DataSet. In fact, we've developed little utilities in VFP for doing that (taking the IDE generated code and generating our own sub-class of that, doing things like making our own properties for things like table names). But I really don't like messing with the generated code ... too error prone if one forgets.
>
>2) Most of our columns *are* nullable, so that's kind of opposite of your sitation where nullable is not as prevalent ... so maybe it makes more sense in your situation, but not in ours.
>
>3) If I understand you correctly, are you saying that Jason changed the type of a column to an object instead of string, int, long or whatever it happens to be? That seems like it's also defeating the whole purpose of a Typed DataSet .... those columns are no longer of a specific type, they've simply become objects and you have to cast them more often. Seems backwards to me, but maybe I'm misunderstanding what you've said.
>
>~~Bonnie
>
>
>
>>Bonnie,
>>
>>I was talking to one of my esteemed colleagues, Jason Mesches, and he came up with a much better solution for dealing with StrongTypingExceptions. After deautomating the strongly-typed dataset class, change the return type of value type properties that can be null in the database to object, that way, all columns are listed as properties and still perform the way you expect, but because of their type, the person using them is reminded that they might be null.
>>
>>I just wish that I had thought of it.
>>
>>David