Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Problem with Model | Compare With

1 view
Skip to first unread message

Kevin Dean [TeamB]

unread,
Jan 22, 2008, 8:39:44 AM1/22/08
to
I have two database diagrams. They each have a common set of tables,
indexes, and foreign keys. The comparison works fine, except for the
foreign keys. Even though table A refers to table B in both diagrams
(same columns, indexes, and foreign key names), the comparison shows that
the reference exists in diagram 1 but not in 2, and again that the
reference exists in diagram 2 but not in 1.

Is there a way around this or is it a bug?

--
Kevin Dean [TeamB]
Dolphin Data Development Ltd.
http://www.datadevelopment.com/

Please see CodeGear's newsgroup guidelines at
http://support.codegear.com/newsgroups/guidelines

ElenaA

unread,
Jan 23, 2008, 2:15:58 AM1/23/08
to
sorry, don't understand. When I compare ERPhysical diagrams for 2 schemas
that both contain similar tables with FK relationships, I can see that FK
edges exist in both (in StructuireCompare pane, double-click on
Children:Node, then expand the Table nodes to see edges).

When I compare 2 schemas (not diagrams, but schemas themselves), I still can
see fk relationships in both schemas


"Kevin Dean [TeamB]" <Kevin.RE...@datadevelopment.com> wrote in
message news:xn0flhjau55...@www.teamb.com...

Kevin Dean [TeamB]

unread,
Jan 23, 2008, 7:25:39 AM1/23/08
to
ElenaA wrote:

>sorry, don't understand. When I compare ERPhysical diagrams for 2 schemas
>that both contain similar tables with FK relationships, I can see that FK
>edges exist in both (in StructuireCompare pane, double-click on
>Children:Node, then expand the Table nodes to see edges).
>
>When I compare 2 schemas (not diagrams, but schemas themselves), I still
>can see fk relationships in both schemas

Create a database diagram.

Take two tables: A and B.

Create a foreign key between A and B, give it a meaningful name (e.g. MyFK).

Create a second database diagram and repeat the above.

Compare the two models.

What you'll see in the comparison under the client table of the FK is two
entries in the "relationship" node. One entry says that the FK exists in
the first diagram but not in the second (indicated by a '+' symbol); the
second entry says that the FK exists in the second diagram but not in the
first (indicated by a '-' symbol). This is despite the fact that both
entries are 100% identical.

There's an interesting side effect of this. I used your suggested trick
of copying objects from one diagram to another by comparing a blank target
diagram with the source diagram. I then selected the table objects I
wanted to copy over. Everything copied over just fine, except for the
foreign keys: they copied over correctly as far as their relationships
went, but their names did not. Instead, I got [erPhysicalRelationship...]
entries for their names.

ElenaA

unread,
Jan 24, 2008, 1:33:39 AM1/24/08
to
still can't recreate. Please, can you clarify your steps?

> Create a second database diagram and repeat the above

what do you mean by creating a second diagram? Do you create a new diagram
for the same schema (right-click the schema, choose New Diagramn), or a new
schema (select a project, New/Schema)? And what do you compare - diagrams or
schemas? A screenshot that shows up the problem ould be also helpful.


As for your second problem (FK name not preserved when copying tables), this
is thje known issue: it's not possible to set 'name' property for
erPhysical::Relationship using Tg EMF API. You'll face similar problems when
trying to do this using, e.g., QVT transformation


"Kevin Dean [TeamB]" <Kevin.RE...@datadevelopment.com> wrote in

message news:xn0flivxv1hx...@www.teamb.com...

0 new messages