Hi Mark,

Based on your description, I understand that you have some Typed
DataSet/DataTables generated from database and will be transferred between
client and server through webservice. However, one of the table column is
set to AllowNull= false while you will need it be set to "true" when using
it at client or server code, correct?

As for the auto-generated typed-dataset, when you reconfigure it from
database, it does overwrite the original one therefore, if we manually make
any changes on the dataset/table adapter, it will be changed after we
update it from database.  Also, I can understand your concern that it's
better to keep data access code away from UI layer.

Currently I think we still need to write some custom code to set the
"AllowNull" property. However, to prevent the code from being overwrite
when update dataset or not coupled with UI layer, you may consider the
following approach:

**In .NET 2.0, auto-generated typed dataset/datatables use parital classes.
Thus, you can also add another partial class file to extend the certain
typed DataSet or DataTable(and its TableAdapter).

#Extending Typed DataSets - Sorting Child Rows
http://www.madprops.org/cs/blogs/mabster/pages/extending-datasets-sorting-ch
ild-rows.aspx

You can add some custom method for the TableAdapter (which change the
AllowNull property of the certain DataTable  or use your own SqlCommand
object for updating, inserting). You encapsulate all these code logic in a
single custom method.

e.g.

===============
public partial class personsDataTable {
           
           private global::System.Data.DataColumn columnid;
           private global::System.Data.DataColumn columnname;
           ...

public MyInit()
{
this.columnname.AllowDBNull = true;
}
..
=============
           

** In your actual code(in client or server application) which use this
TypedDataSet, you can simply call the custom function you defined above(at
the begining when you create an instance of that datatable). Though it
still require you to manually call the method, it reduce much data access
specific code.

How do you think?

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg@microsoft.com.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
From: "Mark Baldwin" <sWozzi3@community.nospam>
Subject: DataSets and default columns
Date: Wed, 9 Apr 2008 14:56:59 +0100

We have a 3 tiered application. Table <tblx> resides in SQL2005, the
DataSet
<dsx> is defined in the web service. The client creates instances of <dsx>
and passes them to the web service for storage/processing.

The table <tblx> has a column "EntryDate" with a default value of
"CURRENT_TIMESTAMP". When the DataSet <dsx> is generated from the table,
the
EntryDate column is set to AllowNulls=false and the INSERT statement in the
TableAdapter includes the EntryDate column.

Before I can use this DataSet I have to change AllowNulls to true,
otherwise
this column has to be filled in by the client before it can be sent the
DataSet to the WebService. I also have to change the TableAdapters INSERT
statement so as not to include the EntryDate column - since its
automatically populated by SQLServer.

This isn't too much of a problem, but everytime I modify the table
structure
I have to remember to do these two things after refreshing the DataSet and
to be honest it's becoming a bit long in the tooth.

Is there a way around these problems? I know I can set the EntryDate column
in the table to AllowNulls but I don't want to do this, it's just not good
practise to allow UI problems to be solved in the data layer.