Frans,

Typed ADO.NET datasets have methods to check for null in each field. Have you thought about doing something like that? Instead of

        if (po.Fields["Issued"].IsNull)

you would say something like

        if (po.IsIssuedNull)

'null' is not a concept of an active entity, that's why the fields aren't there. The concept of using a separate property is a bit vague, as you need to test it every time before you can access the real property, which is a bit odd IMHO.

Another reason why they aren't there is that they're ambiguistic: if I read an entity from the db and field Foo is NULL, do you want IsFooNull to return true? Probably. Now, load the same entity from the db and change a field Bar from "lalala" to null. Do you want to have IsBarNull to return true now? Probably too. However these are 2 different things, IMHO. Perhaps I look at it too strict though...

Not sure I understand the problem. What we are calling fields are really just properties, right? So we can't really set them to null (i.e., pointer null), whereas we can or should be able to set them to db null (come to think of it, I don't know off the top of my head how to do that).

JimFoye wrote:

Not sure I understand the problem. What we are calling fields are really just properties, right? So we can't really set them to null (i.e., pointer null), whereas we can or should be able to set them to db null (come to think of it, I don't know off the top of my head how to do that).

The properties are strongly typed, i.e. 'int', so you can only set the property to an int, not for example DBNull.Value. To do that, you have to use entity.SetNewFieldValue(index, value). There is no other way unfortunately. I could generate for every field 2 methods: Set<fieldname>ToNull() and Is<fieldname>Null (or a method and a property), the thing is, it adds in a project with 100 tables, and 10 fields per table 2000 methods to the project. Initially I didn't want to do that, as I didn't see a lot of use for them really, as most users will work with values other than null. If a user wants these, they're easily added through an include template so they're added to every entity class.

Yeah, I see your point. You have to watch the code-generation bloat.

What about

po.IsFieldDBNull()?

Takes either field name as string or field index?

JimFoye wrote:

What about

po.IsFieldDBNull()?

Takes either field name as string or field index?

Which would be the same as TestOriginalFieldValueForNull(), only should it return true also if the CURRENT value is null (nothing) but the db value was not?

Otis wrote:

JimFoye wrote:

What about

po.IsFieldDBNull()?

Takes either field name as string or field index?

Which would be the same as TestOriginalFieldValueForNull(), only should it return true also if the CURRENT value is null (nothing) but the db value was not?

I didn't know about TestOriginalFieldValueForNull(). Actually that sounds like what I'm looking for.