We have made some changes to the DDT and are planning a build as there are also quite a few new changes including LZMA compression in both the DDT as well as the PackageIt classes.  But this particular issue baffles me a bit as it doesn't make sense.  I believe that it happened, but I just can't see anywhere in the code that this makes sense.  That is why a reproduction would be so helpful.  Glad you got it going.

We got around it, Ill try and reproduce in the SF sample database for you.

I think that there is something else in the mix here, Keith.  I believe that you are dealing with a legitimate issue, but if I can't get it to reproduce, then I can't change anything or look at anything.  Changing the description of a column should not have any effect whatsoever on the defaults.  So that being said, I am wondering if there is something else in the mix.  We have made hundreds if not thousands of changes and then redeployed without this specific issue ever coming up.

Now, we are running a more current version which may have inadvertently resolved the issue you are running into.

Do you have a backup that you can revert to and then isolate this in a test environment so that we can see what is happening?

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

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

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.

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.

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.

Just checking back...

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.