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

>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.