Today, I was challenged with declarative programming, again.  I have a situation where there is a date field in this table, we're using stored procedures, and I'm using the DetailsView for inserting and updating.  Today's challenge is that the datetime field is used in the INSERT stored proc but not the UPDATE stored proc.  So, it should show up in the "New" functionality but not in the "Update". 

ASP.NET does great for fields that show up in both and are not editable (Readonly=true and InsertVisible=false).  With that combination, you would think it should handle a field that is editable only in insert.  It does in the UI, but still passes the field to the Update parameters in the SqlDataSource even though the UpdateParameters does not included the date - thus creating the "too many fields" exception when doing the update action with the database server.

I have found a workaround but I am unsure of the ramifications.  In the DetailsView_ItemUpdating event, there are a lot of possibilities in the passed in parameters of DetailsViewUpdateEventArgs.   Who knew this "e" could be so powerful?  (The pre/post events are wonderful and exist in many data handling places in ASP.NET).  The DetailsViewUpdateEventArgs provides for cancelling the update, viewing the old values and the new values, and even seeing the key value of the update.  In this case, I played around with deleting the un-needed parameters from the NewValues - and it seems to work. 

e.NewValues.RemoveAt(1) 'removes un-needed date parameter, location specific to my stored procedure

One issue that I don't like about this is that I had to remove by ordinal (or position) which could create an issue down the road if someone changes the order of fields for some reason.  I wish the I could remove by key but the NewValues property is a IOrderedDictionary and does include a Remove(key) option.  If I find issues with this, I'll shout it out immediately.