Trouble creating foreign keys

[Thomas Mercer-Hursh]

Using 7.0.817
Now having appropriate datatypes to work with, I am creating some sample data models to serve as a reference for the automated loading I will be doing.  I have defined a few tables using the «table» stereotype (grumble, grumble that I can't create my own) and have used the procedure in the help for creating a foreign key relationship.  I.e., I draw an association between two tables and then right click on the link and select Foreign Keys.  At this point I am presented with two lists of columns from the two tables, but in both lists every column is doubled.  If I try to select a single instance of the appropriate columns from both sides, it complains that I have not selected all of the primary key columns (destination table has a two column primary key).  If I select both instances of each column, then I get "The changes you requested to the table were not successful because they would create duplicate values in the index, primary key, or relationship.  Change the data in the field or fields that contain duplicate data, remove the index, or redefine the index to permit duplicate entries and try again".

Thinking that possibly this relates to issues which have been discussed elsewhere about having a multipart primary key which is unique overall, but whose individual columns are not unique (grumble, grumble), which is true of the destination table in this instance, I poked around in t_attribute and seem to have discovered that IsStatic corresponds to Unique and AllowDuplicates corresponds to NotNull ... which seems backwards, but when I try changing them and then looking at the model, that's the way they come up.  So, I tried making the two columns in the primary key of the destination as NotNull, but not Unique ... but this gives me the same messages when I try to create the foreign key either way.

Also, these unsuccessful foreign key creations are creating a foreign key operation which I then have to delete and it complains that this might introduce inconsistencies.

Does anyone know off hand where the actual foreign key relationship is stored?

[Thomas Mercer-Hursh]

p.s., I run into exactly the same behaviors with two tables where there is only a single primary key in the destination.

[Thomas Mercer-Hursh]

Now using 7.0.818 ... no change.

I do think I have a clue, though.  Prior to creating my own datatypes, I had installed Progress Software's MDG technology which created its own database, datatypes, and stereotypes. While I deleted the datatypes which it had added before adding my own, I thought there might be some interaction here.  So, I have now removed their technology and now when I open the foreign key dialog there are *no* columns showing and the tables show no database name.  So, I would guess that I need to define the existence of the database somewhere other than t_datatype.  Now, if I only knew where...

[Thomas Mercer-Hursh]

Got it!

Turns out that deinstalling the MDG from PSC also deleted all of the datatypes I loaded.

But, more interesting, it turns out that I defined a full set of both DDL and Code datatypes and called them both "OpenEdge".  So, on a hunch, I deleted them all again and went into the XML and changed the code ones to be "OpenEdge ABL" and left the DDL ones as plain "OpenEdge".  *Now*, there is only one instance of each column in the foreign key dialog.  And, all is now well.  Seems to me that the dialog should have been smart enough to use only DDL datatypes, but now I know...