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?

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