Bonnie,

Tables can have a lot of columns. If a few of them are nullable value types, those columns can't be directly accessed using VS.NET's automatically generated strongly-typed dataset classes' properties without risking a StronglyTypedException. You have to use the DataColumn's indexer to check them for null first. I suppose that if you check with an indexer and, if not null, get the value through the property, so still avoid unboxing, but my concern is forgetting for a column that is only very occasionally null.

For nullable value type columns for which a default value doesn't make sense, when I delete the property, I lose the benefit of strongly typed datasets and have to box and unbox values, but only when accessing that particular DataColumn, not all the others. If you have many other value type columns that aren't nullable, you can use the strongly typed dataset's properties to access them and still benefit. For doing major financial number crunching involving thousands of records with value type columns, it's worth using the strongly-typed dataset properties for the non-nullable value type fields and indexing for the nullable ones because I would still avoid tons of boxing and unboxing.

For operations that would require a ton of boxing and unboxing, it makes good sense to still get the the benefit of strongly typed datasets on the columnar level, if not for all the columns in the table. If most of the columns are non-nullable value types, you still benefit. I try to be cheap with CPU cycles, rather than keystrokes, so I would still want to implement strongly-typed data sets for tables in which value type columns are a minority, but I can only defend the obviously useful cases, not my own compulsiveness.

If returning a default value from the property does make sense, I would want to ask myself if I was saving that much space in the database by not converting nullable bits and numbers to the same default. It depends on how much space it requires to store the specific value type and what percentage of your records have it as null. In some cases, my DBA would want to save space.

For bit/bool values that are nullable, a strongly typed dataset property could return a NullableBoolean enum of True, False, or Undefined. I have seen nullable classes online for value types. This must be what they are used for.

I remember that you said that you like the benefit of using Intellisense to get the column name to quote inside a datacolumn indexer. To keep that functionality, I could declare those columns as public uninitialized fields. That would keep the column names accessible via intellisense, but prevent people who are using the strongly-typed dataset class from trying using them to access values since the compiler would complain right away. I could even put in my XML comments to explain it was just a column name reminder. That's pretty hackish and the compiler warnings would annoy me, but it would keep the column names available via Intellisense. I might just declare them all as strings equal to string.Empty and note that they are placeholders in my XML comments.

Make sense? Make crazy sense?

David

>David,
>
>>For nullable columns in the database that map to value types in C# like int, bool, etc., rather than handling the error in its property in the DataSet.cs file, I am going to remove the property from the typed Dataset class so that nullable columns can only be accessed as an object by the columnname indexer, DataRow["columnName"]. That way, no one forgets that they are dealing with an object that could be null.<
>
>Hmmm ... I'm not sure I get the reasoning behind this. If you can only access the column in this manner, doesn't that kind of defeat one of the reasons for using a Typed DataSet?
>
>~~Bonnie
>
>
>>Bonnie,
>>
>>I looked at this issue again and I found a really simple way around this problem.
>>
>>Most of the problems come back to the fact that your TypedDataset.cs class is autogenerated using the XML designer. Since nearly all the tables that I am dealing with are well-established and their structure is not going to change, I don't need the XML designer.
>>
>>My first, less convenient, solution was to edit the .csproj file's XML node for the TypedDataset.cs class and revised the entries for the .xsd and .cs files to break the link between them and turn off autogeneration. A easier, less hacking, solution is to create a new class file, click on .xsd file for the typed Dataset in the Solution Explorer, click the Show All Files button, and copy and paste all the .cs code from the autogenerated .cs file into the new class, and delete the xml-based version Dataset from the project. For people who need the functionality of the XML designer, this wouldn't be a good option, but aside from its initial autogeneration of my Dataset.cs file, I don't use the XML designer to work with strongly typed datasets.
>>
>>For nullable columns in the database that map to value types in C# like int, bool, etc., rather than handling the error in its property in the DataSet.cs file, I am going to remove the property from the typed Dataset class so that nullable columns can only be accessed as an object by the columnname indexer, DataRow["columnName"]. That way, no one forgets that they are dealing with an object that could be null. I could change the property to pick a default value, like -1 for int or false for bool, but sometimes, only null correctly conveys the meaning of the column.
>>
>>Once I am done working with the middle layer and get to the web interface, I was thinking that I would try to figure out a way to turn off autogeneration for the .aspx file. (Whidbey is supposed to ameliorate the current situation.) I was thinking that I would try adding an AutoGen = "false" attribute to the .aspx node to turn it off, but I change the contents and positioning of controls on webforms way too much to work without the designer, so for webforms, I am going to hope Microsoft improves my work life for me.
>>
>>David
>>
>>
>>
>>>David,
>>>
>>>We ran into this issue as well. At the time we decided to program around it when necessary, and yeah, it's a pain, but thankfully one doesn't always have to check for DBNull.Value, depending on what one is doing.
>>>
>>>But, that said, I understand that there is some way to use a custom Typed DataSet generator because I've heard that the one that gets used is merely a plug-in of some sort. I don't have any more information than that, as we decided not to go that route (and I don't remember why ... it was more than 2 years ago) and so I didn't investigate any further at the time.
>>>
>>>I guess this doesn't help you much, other than maybe to know that there probably *is* some way to solve this problem with a custom Typed DataSet generator.
>>>
>>>~~Bonnie
>>>
>>>
>>>
>>>
>>>>I am working with strongly-typed DataSets, hoping to save some boxing and unboxing costs.
>>>>
>>>>In the DataBase table that I am working with, there are columns that can be null.
>>>>
>>>>The strongly-typed DataSet class generated by using the VS Designer exposes the columns in a row via the DataSet.DataRow class properties. The problem is, that for null values, the get methods of the properties merely throw exceptions when they try to parse from a value equal to System.DBNull.
>>>>
>>>>I would think that the get method in the property for database columns that map to reference types like strings and dates should return null (or maybe string.Empty). For value types, an exception seems reasonable.
>>>>
>>>>I would like to revise the properties in the DataRow class to return some kind of dummy value when the actual value is System.DBNull. The problem that I am having is that VS.NET regenerates the .cs file if I make and save any changes in the .xsd file and overwrite changes that I have made. VS.NET does tell me that the .cs file has been modified outside the Source Editor and asks me if I want to reload it, but it would be better if VS.NET didn't modify it at all.
>>>>
>>>>Is there a way to turn this behavior off?
>>>>
>>>>Is customizing the DataSet.DataRow class properties advisable or should I always index into the value in the row first and make sure it isn't System.DBNull first? That seems awkward.