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

It's not an import bug, that is just how the indexes are flagged on an import. If, on an import, the index contains an identity field and is set to unique, it will be marked as a primary index. Your customers table has two indexes, both contain the identify field, both are marked as unique, so both come in as primary indexes. Your customer1 table has two indexes, but only one contains the indentiy field and, as such, it is the only one that comes in as a primary index.

The 'primary' marker is only used for automatically generated indexes or indexes brought in via an import to indicate indexes identified as primary by SMO or unique indexes that include identity fields. You can have more than one of them in some scenarios (as in your Customers table), and after testing the import on your sample table, they came in as expected based on the way you defined the tables in SQL.

It is important to note that these are indexes, not fields. The table didn't come in with two primary keys. It came in with two 'primary' indexes, which would be expected based on the indexes you have defined on your tables.

Hi,



When you try to deploy the imported tables as is you get this error:



X 9/26/2008 9:11:46 AM   -> Creating index 'IX_TestCustomer_01' failed.

X 9/26/2008 9:11:46 AM   -> FailedOperationException

X 9/26/2008 9:11:46 AM   -> ExecuteNonQuery failed for Database 'TestDB'.

X 9/26/2008 9:11:46 AM   -> ExecutionFailureException

X 9/26/2008 9:11:46 AM   -> An exception occurred while executing a Transact-SQL statement or batch.

X 9/26/2008 9:11:46 AM   -> SqlException

X 9/26/2008 9:11:46 AM   -> Table 'TestCustomer' already has a primary key defined on it.



This is our main concern we have hundreds of tables that get imported like these test tables and to manually fix them all would be too time consuming. How can I get around this problem?