I created a profile from my VFP database and successfully deployed all these tables into a SQL Server 2005 database, including a PK and default value of NEWID() on the field CID ( UID )



There are about 100 tables, all have a pk named CID



As a test of my understanding of the DDT, I added a timestamp to the first 5 tables in the profile ( Timestamp datatype Timestamp NULL )



I did not see any option for only deploying some tables so I answered yes to create a package and deployed to server.



It appears the timestamp was added to the first table but after that the alter failed saying there was a constraint problem CID already existed ( see screenshot attached. ) and this error was repeated for every table in the database.



Obviously I'm missing a key concept here. Is there a problem with key fields of the same name with DDT or am I doing something else wrong ?



TIA

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.

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?

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.