Question SQL Server Exception. Object name already exists in database

In a process to load data with SQL Server as target there is a step for installing constraints in the schema replicated. Stambia Designer forms sentences for constraints like

ALTER TABLE [world].[dbo].[countrylanguage]
ADD CONSTRAINT [PRIMARY] PRIMARY KEY ([CountryCode],[Language])

but, for a previous table it create and installed another constraint for a table in the scheme with the same name [PRIMARY], this is why SQL Server raise an exception for "There is already an object named 'PRIMARY' in the database"



Is there a way to let Stambia to assign different names for each constraint or just avoid named it at all and let SQL Server assign them to avoid the error?
or Is there another way to avoid the Exception?

Thanks in advance

Hi,
I'm not 100% sure, but I guess that you are working with the Replicator Rdbms, can you confirm please ?
According to my local tests, the constraint name for the target is generated from the source Metadata.
=> what is the constraint name in the source metadata ?
=> is there another source table with the same "PRIMARY" constraint name ?

Hi,
Yes, the process is working with Stambia Replicator rdbms.
And yes, all the constraints for PK have the same name 'PRIMARY' in the metadata reversed by Stambia
i.e: in Stambia designer we have, for diferent tables
CONSTRAINT `PRIMARY` PRIMARY KEY (`CountryCode`,`Language`)
CONSTRAINT `PRIMARY` PRIMARY KEY (`Code`)

But, as a matter of fact, the tables in the scheme at the database engine of the source hava no name for PK constraints at all.
i.e.: In the source scheme database engine we have
PRIMARY KEY (`CountryCode`,`Language`)
PRIMARY KEY (`Code`)

So, I presume, that the Stambia reverse process assign name by default (in abscence of it) and use always the same for different tables in the scheme.

I just aply a workaround for this issue.
It consists in editting every pk constraint in Stambia for the scheme and change 'PRIMARY' for a distintive name for each table.

Of course we has to be aware that applying this workaround could become a hard and none pleased job when the scheme contain hundreds of objects!

Aditionaly, I detect another Stambia fault getting references for a foreign key

In the source datastore we have
CREATE TABLE `countrylanguage` (
`CountryCode` char(3) NOT NULL DEFAULT '',
`Language` char(30) NOT NULL DEFAULT '',
`IsOfficial` enum('T','F') NOT NULL DEFAULT 'F',
`Percentage` float(4,1) NOT NULL DEFAULT '0.0',
PRIMARY KEY (`CountryCode`,`Language`),
KEY `CountryCode` (`CountryCode`),
CONSTRAINT `countryLanguage_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `country` (`code`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

but Stambia designer generate the metadata
Create table `world`.`countrylanguage`
(
`CountryCode` CHAR(3) NOT NULL,
`Language` CHAR(30) NOT NULL,
`IsOfficial` VARCHAR(1) NOT NULL,
`Percentage` FLOAT NOT NULL
, CONSTRAINT `PRIMARY` PRIMARY KEY (`CountryCode`,`Language`)
,CONSTRAINT `countryLanguage_ibfk_1`
FOREIGN KEY (`CountryCode`)
REFERENCES
()
)

Just like that

Hi,
Please send your metadata and this sample SQL queries to the support team through a new ticket, they will help analyzing / fixing