Column does not allow Nulls eventhough AllowDBNull is set to True

[BrownFingers]

I have a TableAdapter with a primary key value which I populate from a GetNextID stored procedure. The sequence of the primary key value is important, so I only want to call this Stored Procedure after all validation on the TableAdapter is complete. My problem is this, to detect if changes are pending I have to call end edit. When I call this, I get an exception saying CALL_NO does not allow nulls. I have set the AllowDBNull property to true for CALL_NO and I still get this problem.

Any ideas?

 

[cjard]

if a column is listed as the primary key of a DataTable, it cannot accept nulls, regardless of the setting of AllowDBNull

Put a dummy value in there like -1

Please note a TableAdapter is a device for moving data from and to a database. It does not store data. Ensure you call things by their proper names to avoid confusion when posting. Cheers

 

[Sammi13]

DataRow row = myDataTable.NewRow();
if (row["CALL_NO"] == DBNull.Value)
    row["CALL_NO"] = -1;
row.EndEdit();

Is that it? Assigning a dummy value like -1 to the CALL_NO column to work around the constraint of the primary key not accepting null values.

 

[cjard]

To be honest, I think I'd configure the seed and increment so the table itself calculates a value for you. If you have "refresh the datatable" turned on then it doesn't matter what value goes in the row; the db will calculate its own and the adapter will retrieve it. The purpose of having a value locally before save is so other records can be related to it, and those records will have the DB's calc'd value applied by the data relation upon refresh (thus, save the parent, parent gets an Id, children get same id, children can be saved and will relate to parent)

Note that this original query was definitely about strongly typed datatables and your code uses a weakly typed one; either you have a string one that you're using incorrectly, or some of the advice above won't apply unless you've done a lot of work in the background to set up relations etc

I recommend you use strongly typed tables if you don't already