Hi Rick,

>Right now as it stands I have a routine that initializes most values to
>non-null values then explicitly follow up the fields that need to have
>specific values (or null) set. It's not a big deal, but this sort of thing seems very inefficient requriing lots of extra code... (well actually my BO has some code that can do this automatically setting everything to VFP style blanks rather than nulls).

I don't have an answer w.r.t. ADO.net, but in general I've been concluding lately that default values ideally should not even be under the control of the back-end, but rather should be controlled by the BO in the first place. Well, at least whenever you have control over both tiers...

>Dealing with NULLS in ADO.NET is a PITA too because you have use DBNull for all comparisons etc. so I'm even less inclined to ever use NULLs in any data except those that REALLY require it for knowledge of previously unset values (most don't).

In a way, I have the same feeling about NULLS as default values. The BO really needs to make these calls. Of course, you have to do something in the backend to allow NULLs, but beyond that, I really want my BO to control this stuff rather than being faced with the anguish having my data-access strategy limit what I "know" about my data entities.

-- Randy