Unexpected behavior concerning constraint names

TSycamore

hi folks!

I have compared databases with Constraint and Index Names set to Ignore. However, in the synch script, it is still trying to create a new Primary Key exactly the same as one that already exists with a different name - which, of course, fails. I thought this was what I was switching off. Am I wrong?

Michelle T

Ignore Constraint And Index Names ignores the names for the purpose of the comparison, but the synchronization still takes the name of the constraint from the source table.

The option is designed to allow you to see tables with different auto-generated constraint names as equal and avoid unnecessary name synchronization, but if you're creating a constraint or index in synchronization it will still specify a name and that will be the name in the source database.

Is there some way we could make this clearer in the UI / the description that comes up when you hover over the option?

TSycamore

I guess I didn't expect the synch tool to try to create a primary key when one already existed - at least without removing the one that was already there in the target table! Surely it should know it can't do this!??

Michelle T

It should be dropping the primary key from the target table first, yes. Sorry, I didn't spot exactly what it was doing, just the misinterpretation of what the option did.

If you could give me (michelle.taylor@red-gate.com) an example of when it tries to create a primary key on top of another primary key, along with what project options you were using, I'll try to work out what's making it get the actions in the wrong order / fail to generate the drop action. I know there can sometimes be problems along these lines when 'Ignore Indexes' is on, so it's possible that Ignore Constraint And Index Names is causing similar problems.