All went well.  Then realized I didn't want clustered UID pks. Made the change in DDT but DDT could not uncluster the indexes ( error said they had to be dropped and recreated and DDT didn't seem to want to do that )

Okay, so I used T-SQL to drop all constraints, keys etc on all the tables in the sql dbc.  Then I recreated all the pks as non-clustered.

Now I wanted to reimport into DDT.  Decided to do it into a different project.  i think that is where it started to go wrong.  All the structure came over and the indexes came over but they are just unique constraints - not primary keys and will not accept a default value of NEWID()

They show up as primary in the field list

but the index

If I try to add NEWID() as a default value I get

DataLayerSavingException
  The INSERT statement conflicted with the FOREIGN KEY constraint "fk_indexes_indexfields". The conflict occurred in database "StrataFrame", table "dbo.DBEIndexes", column 'idx_pk'.
The statement has been terminated.
SqlException
  The INSERT statement conflicted with the FOREIGN KEY constraint "fk_indexes_indexfields". The conflict occurred in database "StrataFrame", table "dbo.DBEIndexes", column 'idx_pk'.
The statement has been terminated.

I haven't had this problem with my other databases

I tried completely deleting all the DDT projects connected with this database and then importing to a new project in DDT but get the same result.

To test this :

I created a new database called Testit.  One table Names ( ckey UID, cname char(10) )

Created PK on ckey

Imported into a new DDT project and got the same result.  pk_ckey is Unique Constraint, not PK

Am I doing something wrong or is this a bug?  Don't think I had this problem in 1.6

FWIW here is a little more on this to throw in the notes :

After importing tables with UID pks and having them show up in the index node in DDT as a unique constraint but not a pk ( though the pk in the field list is still correctly identifiied ) I did as you suggested - deleted the index in the index node, opened the table in DDT and saved it.  The PK then showed correctly on the node ( you asked about this earlier in this thread )

I manually corrected all the tables in the DDT this way, dropped the database in SQL Server and deployed from DDT.

All seems well except there is a constraint that would not be there if this had been created in SQL.

I have no idea if this is ever going to make a difference on the sql end and if this is just an anomaly created by dropping the constraint from the index node in DDT and having the Pk automatically replace it.  But it is a little disturbing that there is nothing in DDT ( or at least I don't see it )  to indicate this constraint is still going to be deployed after being deleted.  ( I realize a pk is itself a constraint, but the DF_agent_ckey seems gratuitous and I don't know if it may get me in trouble in some other way so I am just going to write a script in sql to drop all the dk_ constraints )  Just wanted you to know that deleting it in the DDT node doesn't seem to keep it from being deployed.

I'm attaching the package just so you can see what is under the hood. 

Realize you have other stuff on your plate and I can work around this for now but

How would I roll back to DDT 1.6 for now as I don't think the importing from SQL table problem exists there?

TIA

Charles