Bonnie,

For us, since nullable columns are fairly uncommon and some nullable columns may be populated for the vast majority of records, I prefer returning an object type so that when I use the typed DataSet, if I access that property, I have to cast it from object and I remember it could be null. If I forget, I get a compile error. If I relied on using the indexers, a null value would result in a run-time error. (I try to make my mistakes as privately as I can.)

We can both look forward to the nullable type utopia that Dave Foderick has pointed out on the horizon.

David

>David,
>
>>>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 Typed DataSet contains an IsNull method for each property. So, say you have a property called MyProp. There will be a method called IsMyPropNull(). So, you can either use that to determine if a column contains DBNull, or you can use the DataRow indexer to do it:
>

>// either this:
>    MyDataSet.MyTable[0].IsMyPropNull == true
>// or this:
>    MyDataSet.MyTable[0]["MyProp"] == DBNull.Value
>

>OK, yeah, the programmer might forget that he/she has to do that. Oh well ... they won't forget too many times before it gets drilled into their head (by the rest of us screaming at them <g>).
>
>~~Bonnie