BUG: Weird FK behaviour

[Paolo F Cantoni]

In a related posting [size=13]BUG: Table Datatypes[/size], I hint that EA need to create more element types (such as Table).  This is to get around problems caused by what I consider an incorrect use of stereotypes.

Because I'm creating data models, I'm not reverse engineering a database.  I've ended up with a column that's NOT part of a foreign key constraint yet has the "FK" indicator against it.  This is caused by non-removal if the FK constraint is destroyed...

I can't do anything (short of deleting the column and adding it again ) of getting rid of it...

When I open a Foreign Key dialog, almost all columns in the list appear more than once.  I've checked the database - they are only present once.  The datatypes are for an abstract database called "Conceptual" but why most datatypes (but not  others) cause duplicate entries in the FL constraint dialog, is beyond me...

Anyone else seen this behaviour?

Paolo

[size=10]Using EA in spite of EA, NOT because of it![/size] ^TM[/color]

[Paolo F Cantoni]

Further to this, if the duplicated column is to be the target of a Foreign Key Constraint, you are in a catch-22

You have to select both copies of both ends, otherwise EA won't allow you to save.  You then get told there was a unique index violation and the Foreign key wasn't stored.

You can't delete this operation  - because it's part of a (non-existent or corrupted) foreign key constraint.

Project integrity check doesn't find/fix it.

The only way is by direct DB surgery...

Paolo

[Paolo F Cantoni]

OK... If you have the SAME product name in BOTH the Code and DDL datatypes list - you will get this behaviour and the consequential problems all over the place...

Why this should be the case is not known to me...

Fix it! ASAP!

Because reference information management is additive only (see other bug report) - this can come about and I was only able to finally sort it by clearing the database of the spurious datatypes.

Finally, since there isn't any way to clear out a datatype product from the UI, you can only do it via the database!

Paolo

[thomaskilian]

I've been there long time ago. Thought it was my fault Luckily I do not need to design DBs currently.

[Paolo F Cantoni]

Because I'm creating data models, I'm not reverse engineering a database.  I've ended up with a column that's NOT part of a foreign key constraint yet has the "FK" indicator against it.  This is caused by non-removal if the FK constraint is destroyed...

This is really starting to hurt as there are a number of consequential anomalous behaviours - caused, I believe, by this bug.  

Does anyone know where the "I am part of a an FK" fact is stored within the database?  I can then attempt direct surgery.

Otherwise I am forced to not only delete the Relationship but also the affected Columns!  This, naturally, plays havoc with my DB design activities.  Sometimes (depending on the circumstances, I can't even do that and I can only remove the offending column directly in the DB.  

Paolo

[size=10]Using EA in spite of EA, NOT because of it![/size] ^TM[/color]

[thomaskilian]

Sorry, but no :-/ I luckily did never have real force to go into extensive DB design with EA.