As I mentioned to you before the missing PK's in that database was a different issue in how that particular db was created. We have multiple copies of this DB floating around and in my rush to get you the MDF I didn't realize I was attaching a "bad" one. But, my problem again is not the PKs - the PK issues I had before seem to be resolved with the newest DDT version - my PKs are all UID and have defaults of newid() already in my current db and I don't need DDT to create those for me. I'm just trying to add defaults to existing fields using DDT but because some of my fields were named the same between multiple tables when I deploy the updated DDT package back to the existing db that doesn't have default values defined on the non-PK fields I get conflict errors and the defaults do not get added to some of the tables.

I've taken a lot of interest in this thread since I'm very interested in DDT and Randy Jean is a long-time (and highly accomplished) VFE user who I know to be saner than he sounds

I can reproduce the errors that Randy is talking about consistently.  They aren't the result of a 'bug' in DDT so much as the result of what I think might be a bug in SQL Server that could easily be worked around in DDT by using the same naming convention for constraints on default values that SQL uses and that DDT itself uses when creating the constraint at the same time as the field (  i.e. DF_<tablename> prepended to the field name )

First, this error can be reproduced entirely outside DDT.  Create database junk.  Create tables
table1 and table2.  pkfield (autoint) , cname (char(10), ncount (int) for both tables.

script constraints for table1 where ('') and (0) are applied to the non pk fields naming the constraint the same as the fieldname - no prepending

use same script only changing tablename to create constraints for the second table and you will get the error that an object named cname already exists in the database.

Probably shouldn't happen, but without the prepending it does.

When a constraint is added in DDT to a field that does not previously have a constraint DDT names the constraint exactly the same as the field name.  If two constraints are added to two different tables in the package on fields of the same name, the error will occur. 

I've reproduced this numerous times with numerous scenarios.  I get slightly different result from Randy in that when I follow his test steps of creating two tables with identical fields, no constraints, import them to DDT, add constraints, deploy I don't get the error.  But if I add two identical fields to the two tables in DDT, deploy, then add constraints and deploy I get the error every time when the second table tries to create the constraint.

I'm sure just changing the naming convention DDT uses in these scenarios to the standard SQL convention would fix it and if that's not a real big deal I'd say it would be greatly appreciated.

Meanwhile, is there a spot in the strataframe database (or in the package) where the constraint name that is going to be created can be tweaked prior to deployment?

I can see where this might be a showstopper for deploying these kinds of changes.

I'd be happy to reproduce all this in a 3 minute demo via logmein if anybody at Microfour would like to see it. 

Don't worry abou the video, we made a change to the DatabaseMigrator that should prevent this from happening.

In a scenario where the DDT is deploying to a database that existing before the DDT was used for deployment, an issue could occur where the default contraints are not properly created and try to use the name of the column name.  A workaround has been implemented within the DDT that will prevent this from happening.

Note: You will need to be on the 1.6.6 beta for this to work.

Thanks Trent!



For any lurkers there was some difficulty getting to where Trent could readily re-produce the problem which probably had a lot to do with I was sending him invalid scripts and MDF files to look at from my mucked up development environment which I have multiple copies of my database in various states of disrepair. Once we got through a simple example of how to re-produce the problem from scratch the fix was posted in minutes! Now that is what I call top notch service and support.

I completely agree with Randy.  This was a tough one because of the somewhat strange behavior of SQL server itself.  Very impressive that Microfour was able to resolve this so quickly.

I think DDT is a very significant tool and it just keeps getting better !

Thanks for your comments, guys!  And glad we got to the bottom of it!