Here are my tables:



CREATE TABLE TestCustomer

(

CustomerID INTEGER IDENTITY CONSTRAINT IX_TestCustomer_00 PRIMARY KEY CLUSTERED,

CustomerCode VARCHAR(10),

CustomerName VARCHAR(100),

Active CHAR(1)

)

GO

CREATE UNIQUE INDEX IX_Customer_01 ON TestCustomer(CustomerCode,CustomerID)



go

CREATE TABLE TestCustomer1

(

CustomerID INTEGER IDENTITY CONSTRAINT IX_TestCustomer1_00 PRIMARY KEY CLUSTERED,

CustomerCode VARCHAR(10),

CustomerName VARCHAR(100),

Active CHAR(1)

)

GO

CREATE UNIQUE INDEX IX_Customer_01 ON TestCustomer1(CustomerCode)



After I import the tables I get more than one primary key . It seems to be a bug in the import tool. I am still using v1.6.0

I do see what you are talking about on the deployment now.

The best solution here would be to fix your meta-data in the DDT to line up as desired so that your deployments can proceed without issue. We try to get you as close as possible with the automation on the import, but in your specific scenario the DDT can't decern which index you want to be primary and, as such, is creating two primary index on two tables. In that case, simply delete the one you don't wish to be a primary index and recreate it manually. 

This would be a one time fix on your part, once you have all the indexes limited to one primary index per table within the DDT, your deployments should work without issue from that point forward.

We appreciate you taking time in looking into this. We considered implementing your solution. But in our schema, it is not going to be practical. We have 1700 indexes to manually delete and recreate. Is there any other option you have to automate this process of deleting an index and recreating as a non-primary index?

We are even open to manually changing your DDT files (if they are in XML format or any such format?)

We would love to use your tool but for this initial hiccup of getting a clean definition.