DB Comparison/synchronization issue 2 - Object DDL creation
Posted: Tue 08 Dec 2009 12:02
Hello Support Team,
I have a table to define a n:m relation and it is defined in my project file as following:
when synchoniszing with db server, dbForge Studio generates this DDL for the table above:
the verification ends in state "to update", because it adds the
to the DDL statement, but this is absolutly incorrect for this table and is not defined in our project file.
Normally we have data like this in the such kind of table:
So why does dbForge Studio generate this index?
Executing the synchronisation script will also fail with "duplicate key", because of the data.
I have a table to define a n:m relation and it is defined in my project file as following:
Code: Select all
CREATE TABLE auth_right_group (
GRPID INT(11) NOT NULL COMMENT 'group id',
RIGHTID INT(11) NOT NULL UNIQUE COMMENT 'right ID',
PRIMARY KEY (GRPID, RIGHTID),
INDEX idx_auth_right_group_grpid USING BTREE (GRPID),
INDEX idx_auth_right_group_rightid USING BTREE (RIGHTID),
CONSTRAINT fk_auth_right_group_auth_group FOREIGN KEY (GRPID)
REFERENCES auth_group(GRPID) ON DELETE CASCADE,
CONSTRAINT fk_auth_right_group_auth_right FOREIGN KEY (RIGHTID)
REFERENCES auth_right(RIGHTID) ON DELETE CASCADE
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;
Code: Select all
CREATE TABLE auth_right_group (
GRPID INT(11) NOT NULL COMMENT 'group id',
RIGHTID INT(11) NOT NULL COMMENT 'right ID',
PRIMARY KEY (GRPID, RIGHTID),
INDEX idx_auth_right_group_grpid USING BTREE (GRPID),
INDEX idx_auth_right_group_rightid USING BTREE (RIGHTID),
CONSTRAINT fk_auth_right_group_auth_group FOREIGN KEY (GRPID)
REFERENCES auth_group(GRPID) ON DELETE CASCADE,
CONSTRAINT fk_auth_right_group_auth_right FOREIGN KEY (RIGHTID)
REFERENCES auth_right(RIGHTID) ON DELETE CASCADE,
UNIQUE INDEX RIGHTID (RIGHTID)
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci
Code: Select all
UNIQUE INDEX RIGHTID (RIGHTID)
Normally we have data like this in the such kind of table:
Code: Select all
1 1
1 2
2 1
2 2
2 3
Executing the synchronisation script will also fail with "duplicate key", because of the data.