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

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 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.

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.

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. 

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.

What are you defining as a PK field here...that could be the problem here.  Yesterday when I looked at your structures, you had unique clustered indexes, but no primary keys.  Do you have your PKs set as identity columns?  Is this the step I am missing here?

Trent is trying to help me but we don't seem to be getting to the heart of the problem. If anyone else cares to test the following scenario (I've re-produced in 1.6.6) and can confirm or explain the issue better than I maybe we can get this resolved with some community help:



Create a new database in SQL 2005.



Create 2 tables with a PK and a few other fields – name the non-pk fields the SAME name and make the same type in both tables. DO NOT ADD defaults to the non-PK columns. Import this database into a new DDT project.



Add defaults to all of the non-PK fields in DDT, such as (‘’), etc.



Attempt to deploy this package to the existing SQL database.



You WILL get an error on the 2nd table when it tries to create the default constraints due to it using the field name rather than df_tablename_fieldname. Now, if you deploy this same DDT package to a new database, the constraints are created using the proper naming convention and these errors do not occur. However, we are trying to update an existing deployed database (actually, multiple local SQL Express databases) so re-creating the database to add the defaults is not an option and we're trying to avoid having to create scripts to do this.

Can't believe it... you caught me! How do you do that?

Just FYI for those reading this post, there were issues with the profile and how the database from which the profile was imported came in.  We have been dealing with this via email and PMs.  I figured that there would be some curious individuals