the varcher null in DB should map to null in generated code, why I get ""?

It is annoy that I need to check using [destinationPersonalInfo.TestOriginalFieldValueForNull] method. I even did not change any properties of the entity.

wangchao1687 wrote:

the varcher null in DB should map to null in generated code, why I get ""?

because all NULL values are converted to the default value for the .NET type of the field mapped onto the column. For strings you could use null, though for int for example, you can't, so there is a universal way to deal with this: TypeDefaultValue.cs/vb has the default values for NULL-ed fields.

It is annoy that I need to check using [destinationPersonalInfo.TestOriginalFieldValueForNull] method. I even did not change any properties of the entity.

There is no other way, how would you test if some int field is NULL? You can't. You could define '-1' or so as 'NULL', but what if your app specs change and -1 becomes a valid value? (in the early '90-ies, some people used 9-9-99 as a NULL date in systems, which gave problems when the system was still around at that date. )

I personally wouldn't of minded if you had used something similar to http://nullabletypes.sourceforge.net/ in your solution, I'm sure there is a performance hit somewhere but honestly for DB stuff I don't see it as an issue, but this library adds one of the biggest features of 2.0 in my opinion to today's apps.

I will be honest I haven't tested these extensively with every 3rd party control, but it does look attractive.

John

I had to make a decision when writing teh initial code and I first thought of nullable types. Though I had some bad experiences with non-native types for properties in LLBLGen 1.x (the dal generator), especially when VB.NET developers wanted to set the properties to a value, because VB.NET doesn't support operator overloading, it therefore can't use implicit converter operators.

Which means that if you wanted to set an int field, you'd need to use syntaxis like new NullableIntType(value) (bogus class name, but you get the idea).

This was therefore not an option unfortunately. Till the .NET 2.0 nullable types, using NULL values in code will stay a problem..