Null problem with databinding

We aretired of null values coming out of from the database andwe are directly coding behind UI decleratively.

We set up anull value coding standarts but I wonder what are the disadvantages to our approach

DataType The default value we send ALLOW NULL

int,bit,decimal 0 NO
nvarchar(string) " "(one space) NO
datetime YES
binary YES

*in datetime we do not allow nulls in places such as _CREATEDATE and _LASTMODIFYDATE fields.

What are other approaches for null besides writing your own layer to handle it ?

It really depends on how you are using the values once they are pulled from the db as to how to handle the null values. If you are wanting to keep all validation on the db, then I think you have the best approach. If you are using an XML dataset/tableadapter provided in VS2005, then you can click each individual item in the dataset and there is a property for NullValue. By default it is set to ThrowException, you can change that to Null or EmptyString. In my code if I am just pulling values from the db without usinig a dataset, I validate using If Not .... IS DBNull.Value Then do the databinding, this will catch all null values before a databind. You could also format all of your insert statements to insert some default value instead inserting nothing. However, I have done that too and you run into other problems down the road so it is not recommended. The best advice to handling null values on web forms is checking it against IS DBNull.Value. Hope that helps.|||

jcrabtreesla:

You could also format all of your insert statements to insert some default value instead inserting nothing. However, I have done that too and you run into other problems down the road so it is not recommended.

what kind of problems do I run into? can u explain it further please?

|||For instance if you inserted a string value of "N/A" or "None" into every field the user leaves blank. Then when you go to databind that data, you can run into many issues. One would be if you are databinding to a drop down list you don't want to display "N/A" 100 or 1000 times for every "N/A" in the db. You would have to write extra code to filter that out. I guess when I stated "problems" what I really meant was extra coding work for the developer. Also, back when I used to do that, I read an article somewhere that outlined some more issues, one was the size of the data being retrieved (a string value even if it is small, has more byte size than a null value). But the article also gave the alternatives that I use now, which is what I relayed to you. To me, logically it really shouldn't matter if it has a value of Null or "N/A", but when you get large amounts of that data it causes the developer headaches and can cause latency issues when pulling from the DB. I have just learned to handle the Null values with error trapping rather than taking the easy way out and inserting a string value. In the short term it seems like more work to error trap all that, but I think in the long run you'll be happy. Hope that gives you more info. Do a goole search on this too, you might stumble on that article I had read.