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