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?

Any response to this?

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!

Dustin,

Thanks for your response. I understand and agree with what you've said above.

As for the data types... Lets say I have this.

char(10) with a default of ('default')

If I change to varchar(10) and deploy the changes then the datatype changes in the database target but the default value is then blank. This happens even though I can still see the default setting in the DDT. Changing from one type to another like above does not clear the default value setting which I would assume makes perfect sense since they're both string values but somehow changing the data type in the database clears out the default value setting.

So even though it blanks out the default in the DB I can still open the DDT and see the default set in there.

Thanks again for getting back to me.

Just checking back...

Matt,

I would like to have a sample on this as we use the DDT and the defaults daily.  So this could be related to a specific data type or scenario that we just haven't run into.  We have extremely large data sets in our medical application and I am notorious for changing the default values, adding fields, renaming, etc.  So I really need a concrete reproducable sample.  If it is really simple, then you can give the steps and we will create the database on this side.  Otherwise, we will need to get a sample PKG and MDF or BAK from you so we can reproduce it on this side.  Thanks.

What's the best way to pass along my schema to you?

This particular problem still exists for me. The attached image shows one of the fields in question. If I change the field type to varchar(8) then the DDT still shows my default value as it was. However, when I run it against the database, the field type is changed properly but the default value is lost. I can close down the DDT and then reopen the profile and it will show varchar(8) still on that field with the default value but it will never put the default value back on that field in the deployed database.

Even if I change the type back to char(8) it will not put the default back onto that field and will still show it set in the DDT.

Creating a new database from scratch works and shows the default value.

I will see if I can reproduce this through the screen shot.  But just out of curiosity, why are you using a Char field?  You would be better off using a VarChar field.  Really the only time that a Char is ever really necessary is when you are going to have a fixed length field that is always going to be completed filled.  Otherwise, you are better off using a VarChar field.  This doesn't change anything in regards to looking at the problem, just an observation.

Trent,

I was just wondering if there have been any advances made. Since we have not begun using our new SQL backend yet we are still able to create a new database each time. This avoids the problem but once we lock in and go live applying updates/changes will become an issue.

The issue is in regards to changing a field data type. If you change from one type to another compatable type where the default value set would still be valid. Running the DDT against that database will change the data type but drop the default value. Running it multiple times after that never puts the default value back even though it is shown in the DDT as being set.

I did also check to make sure we were running the latest version which we are.

Thanks
Matt

We just hit it in a major way; we decided we wanted to change the field description for all our foreign key fields to simply remove the word “Foreign” so “Customer Foreign Key” became “Customer Key”. That was the only change that was made and now all the default values for all our foreign key fields are blank and will not redeploy correctly despite the values being correct in the DDT. Just like in this post.

Can you please provide any further insight you may have into this issue?

Thank you very much.

Keith

Keith Chisarik