Greetings all, In the generated code (Adapter), for any Date property the GET part checks if the read value is nothing and then consults a class in the database generic code to replace this NOTHING (NULL) value with another value that can be more easily handeled in code. For example, NULL dates are replaced withDate.MinValue. This approach seems to solve only half the problem: 1- The UI control displaying this DATE value should be setup so that it uunderstands that a special date value (like Date.MinValue) should be displayed as a NULL Date. This proved to be easy enough especially in our DevExpress controls where the DateEdit control has a property (NullDate) that does just that. 2- When the UI user wants to enter a NULL date value, he would delete the date value in the date UI control which internally stores (Date.MinValue). When attemting to save this entity, a value of Date.MinValue would be written to SQL which would cause OverFlow (SQL can't handle dates before 1/1/1735!!). What the generated code should do (in the Date property's SET) is handle the reverse of what it was doing in the GET part. If the VALUE being set is Date.MinValue then SET this proprty's variable to NOTHING (NULL).

Now I know this approach is NOT perfect (especially that the same logic is NOT easily extended to other non-nullable types like BOOLEAN and numbers) but I always found that dates repesented the most difficult non-nullable type to handle.

On another note, I read somewhere that MS are beefing up NULL support in .NET2.0. Does that meen the end of the UI developers NULL problems...

OMAR

Your approach can't be used with other value types, which is why it's not done that way. NULL handling is cumbersome if you want to use typed properties

I don't like solutions where a given value is marked as 'the null value' as that's a moving target. Who can't remember the '9-9-99' date which was used a lot as a flag it wasn't in use, ... till it became september 9, 99.

With .NET 2.0, nullable types will solve this problem. (That is, unless MS forgets to make one valuetype not nullable). They still haven't implemented conversions between DBNull.Value and int& for example, but that's only a problem for the inner core code, not for the entities