>>>In my opinion it is more than OK. I prefer no NULLs (unless a compelling reason to do so) and all columns with defaults ( makes inserts a lot easier as well )
>I did that in my VFP days, but with .NET I've stopped using the defaults in the SQL table and I set the default values in the code.
>When I add a row, I call a function that loops thru all the columns in the datatable, and based on the type, sets the default values in the datatable row.
>
>
>Why?
>
>A. I had some problems a few times with the constraints created by the default values when handling the tables in SQL
>B. I kept forgetting to do it when I added columns and sometimes I put the wrong values in.
>
>The function never misses a column or sets the default incorrectly.

I find putting it in the table design works better for me . If I need to do an alter table and add columns I need default values unless I want to allow nulls. Can't do that on front end. My sps need to be able to insert into a table and get the defaults. How can I do that if my defaults are all set on the front end?

My experience has been the reverse from yours. In my VFP days I never worried about the backend beyond columns names and data types and maybe a generated PK ( though with VFP I used a lot of GUIDs) ( and I confess I was pretty loose about just allowing nulls on everything since I handled in my remote view the creation of a properly typed blank value on new rows. )

But in .NET ( and in an environment where I use a lot of SPs and so do a lot of other people that hit the data I find I need to have the backend handle a lot - especially defaults. Currently I am doing a lot of SP work driven by SSIS against tables that originally I only hit from my VFP or C# front ends. If they allowed nulls or especially if they did not have default values I would have a lot more work on my hands.