t_glossary Inconsistent schema definition

[Paolo F Cantoni]

The definition of t_Glossary is inconsistent in the .EAP schema.  The SQLServer and .accdb schema have the primary key as GlossaryID whereas the .EAP schema has Term as the primary key.  This has caused problems with transferring projects.

Which is correct?  And if GlossaryID, how are duplicate terms handled?

Reported,
Paolo

[Eve]

Just checked all the current schemas except both access varieties. (I don't have access installed to check the files themselves) They all have the primary key as GlossaryID.

I can see that the difference was identified as part of the reviews that led to the schema updates that are on the website now. Version 13 does include updated eap files as well, have you checked those?

[Paolo F Cantoni]

Hi Simon,

As soon as I spotted the problem, I downloaded all the latest schemas from the website.  I then opened them and checked.  The EABase1220.eap file (Jet4) had the Term as the PK.

I can't check the v13 EAP files as we've the later versions of Access that won't support Access 97 files.

So, as to my original question, how does /should EA support duplicate terms?  I wouldn't have thought it should. If you have multiple definitions for the same term,  the definitions should be aggregated into one.  Consequently it makes sense for Term to be a unique key and GlossaryID to be the SK (PK).

Thoughts?
Paolo

[Eve]

The EA gui prevents duplicate terms being created, and lookup only looks for the first matching term.

I have seen requests from users to have glossary terms being specified in multiple categories. If we ever wanted that function a unique index on term wouldn't be appropriate.

FYI -
Version 13 has an option Configure | Model | Check Integrity | Manage .EAP File | Update .EAP File Indexes...

If you run that on your JET 4 model you should find that it is up to date with the latest schema definitions (including the PK on t_glossary)

It sounds like the base JET 4 model on our website hasn't been updated.

[Paolo F Cantoni]

The EA gui prevents duplicate terms being created, and lookup only looks for the first matching term.

I have seen requests from users to have glossary terms being specified in multiple categories. If we ever wanted that function a unique index on term wouldn't be appropriate.

FYI -
Version 13 has an option Configure | Model | Check Integrity | Manage .EAP File | Update .EAP File Indexes...

If you run that on your JET 4 model you should find that it is up to date with the latest schema definitions (including the PK on t_glossary)

It sounds like the base JET 4 model on our website hasn't been updated.

Thanks Simon,

My understanding (and observed behaviour)  of the above is:
While the PK of t_glossary is GlossaryID, the UI will only allow a single term with a given value to be entered.  If you go to the DB direct, although you can add multiple terms with the same value (whether in different types or not), the UI will render ONLY one of them (presumably at random).

Consequently, for the present, both Term and GlossaryID are unique identifiers of a Gloss.

[Eve]

If you go to the DB direct, although you can add multiple terms with the same value (whether in different types or not), the UI behavior will be undefined.

At a guess. Glossary lists will probably still display all entries, editing any may be broken or prevented. Tooltips will display one, I don't know if it will be the first or last the db returns.