Matt,

• What data type is the field?
• What was the original default value?
• What are you changing the default value to?

In regards to the SPROCs and Views, yes, the DDT drops and re-adds those each time the project is deployed. Since the DDT allows you to update a user from older versions straght to the newest version without going through interim steps, there isn't any way to know how out of date the SPROC, Views, etc. are without sophisticated versioning logic. It is much simpler to simply drop the DDT managed items and re-add them with each deploy .  FYI, the deployment won't drop anything not created by the DDT, so if you are doing anything manually or using a different process, they should be safe. It checks to make sure the "DDT_Priority" extended property exists on the item (SPROC, View, UDF, etc.) before dropping it.

Thanks!

Any response to this?

We're having an issue with the DDT when making changes to a field. If there is a default value and running for the first time to create the database, then the default is set. If later a change is made to that field and those changes deloyed to the same database, then the default is removed from that field in the database. Even running another time shows the field default as blank when the DDT still has the default value set.

The other part with indexes and triggers is more of a question regarding procedure. It appears that indexes and triggers are always dropped and created even if there were no changes to a particular table. Is this typical?