Generate Dataset does not carry over Default Values from Database

  • Thread starter Thread starter TommyS
  • Start date Start date
T

TommyS

I'm working with VS.NET 2003 and SQL Server 2000.

After having created a sqlDataAdapter and a sqlConnection by dragging
a database table from Server Explorer onto the form's design surface,
I then generate a dataset from the sqlDataAdapter...you know, the
standard approach for generating a dataset from a pre-existing SQL
server table.

The problem is that the default values that are specified in the
table's underlying design (which you can view in Server Explorer or
SQL Enterprise Manager) are not carried over to the generated dataset.
To verify this, you can right-click on the dataset (in the form's
design view), click "Dataset Properties...", expand the node for the
table in question, click on the field you want to examine, and look at
the DefaultValue property. It will always be set to <DBNull>, no
matter what you actually specify as the default value when designing
the table. (Also, it doesn't matter if that field allows NULLs or
not, the DefaultValue property is always set to <DBNull>.)

Of course, I can override the DefaultValue property in the code.
However, the whole point with all these automated features in VS.NET
is to reduce that sort of overhead.

So is this a bug in VS.NET, or just a current limitation? And is
there any way to get this to work as hoped (i.e., to get the
DefaultValue property to match that of the table's design)?

Thanks in advance,
Tom
 
I perfeclty agree with you this seems to be a bug, actually ... a pair
of bugs.
Firstly the DateTimePicker and CheckBox controls DO need to have
default values, otherwise a new record does not get inserted into the
database table.

Secondly when we "manually" set the default values to the dataset
shema, they get overwritten (actually blanked out) by the next
GENERATE DATASET feature.

To workaround this problem, I set the default values in the form
constructor.

I don't hope to see these bugs in WIDBY.




[email protected] (TommyS) wrote in message news: said:
Of course, I can override the DefaultValue property in the code.
However, the whole point with all these automated features in VS.NET
is to reduce that sort of overhead.
...
So is this a bug in VS.NET, or just a current limitation? And is
there any way to get this to work as hoped (i.e., to get the
DefaultValue property to match that of the table's design)?
....
 
Back
Top