Problems with connections

The XREF construction is powerful but can cause its own problems. XREF makes several assumptions about the class it "XREFs". First, it assumes that the target class exists. Second, it assumes that the target class contains the named label. Third, it assumes that a field follows the label. Finally, it assumes that the field will be able to receive an object from the XREFed class. If an XREF doesn't work, one of these is invalid. In addition, the ACEDB software imposes some restrictions on how XREFs are interpreted.

Since version 4.0, ACEDB has contained a models parser which is invoked upon reinitialization or whenever the models are read in. The parser can detect a variety of errors.

Links between objects should be carefully tested. You should be aware of certain pitfalls:

Object self-reference is forbidden

 A very important restriction applies to links within a class: an object cannot link to itself. The perfectly valid model

?TShirt Resembles ?TShirt
cannot be used to enter data that says

TShirt : sam19
Resembles sam19

A target field accepts only one kind of class

 The problem that causes the most frustration to new designers is that they forget XREF "sends" the name of an object from a specific class to the target.

Consider these models containing XREFs:

?TShirt      Borrowed_by ?Person XREF Borrowed
 
?Person      Borrowed ?Auto XREF Borrowed_by
 
?Auto        Borrowed_by ?Person XREF Borrowed
What is wrong here? The first model is attempting to send a ?TShirt object to a field in ?Person reserved for ?Auto objects. However, the second and third models together are valid. An error of this sort can go unnoticed if you do not attempt to activate the link from the ?TShirt side with real data. Perhaps most of your data is entered from the auto side. Then one day you enter

Person : "Sarah"
Borrowed sam12
and discover two things. First of all, the Borrowed_by field in sam12 (assuming sam12 already exists) has not been filled in. Second, there is a new member of the ?Auto class called sam12, which is not what you intended at all. Furthermore, an attempt to enter

TShirt : sam12
Borrowed_by Sarah
will fail with an error.

Multiple XREFs should not point to the same target

You might be wondering if it is possible at all for two XREFs to point to the same target. The answer is 'yes' as the following model demonstrates:

?TShirt Borrowed_by ?Person XREF Has
        Stolen_by ?Person XREF Has

?Person Has ?TShirt
However, the ACEDB developers urge that this structure be avoided (it is "bad style" and may be forbidden in later releases) as it lends itself to a potential ambiguity:

TShirt : sam25b
Borrowed_by Paul
Stolen_by Paul
This fills in Paul's "Has" field, which seems reasonable, but now what happens if we delete this link from the Paul object? Should this affect sam25b's "Borrowed_by" field, or the "Stolen_by" field, or both of them? The recommended model is 
?TShirt Borrowed_by ?Person XREF Borrowed
        Stolen_by ?Person XREF Stole

?Person Borrowed ?TShirt
        Stole ?TShirt

Targeted field must be adjacent to the targeted tag

 The XREF structure contains the name of a tag in the target object; that tag must be followed immediately by the field to be filled. This rule leads to two kinds of problems.

First, in structures involving "vectors", which are tags followed by multiple fields, there is no way to use an XREF to fill anything but the field closest to the named tag:

?Rumor        Source ?Person ?Meeting
 
?Meeting      Gossip ?Rumor XREF Source
Thus entering this data

Meeting : "Cat Genetics Conference, 1993"
Gossip "ET (extra toes) gene cloned"
will attempt to place the ?Meeting object called "Cat Genetics Conference, 1993" into the first field following the Source label in ?Rumor. But that field is reserved for a ?Person, not a ?Meeting and the attempt will fail.

Second, in structures containing multiple labels, the rule still applies:

?Reference Refers_to Locus ?Locus

?Locus Reference ?Reference XREF Refers_to
The XREF from ?Locus will be unable to locate its target field--expected to be adjacent to the tag "Refers_to"--in ?Reference. An error will occur if you try to activate this XREF with data.

Set order can be changed by XREF

Another kind of problem occurs if you are using sets to represent ordered information, for example, the authors for a publication. This particular case has achieved "classic" status among ACEDB administrators. The offending structures are

?Reference Author ?Author XREF Reference
 
?Author Reference ?Reference XREF Author
If data is entered from the ?Author side, XREF has no way of knowing what the "proper" order of authors is in the reference object. Therefore, this data:

Reference : abcde
Author "Jones, Sally"
Author "Smith, Bill"
Author "Bond, James"
 
Reference : fghij
Author "Smith, Bill"
Author "Bond, James"
Author "Jones, Sally"
is NOT equivalent to entering: 

 
Author : "Jones, Sally"
Reference abcde
Reference fghij
 
Author : "Smith, Bill"
Reference abcde
Reference fghij
 
Author : "Bond, James"
Reference abcde
Reference fghij
...since the two references would end up with the authors in the same order. This problem can occur if you dump data from the database and then re-enter it; the dump will include all ?Author and ?Reference entries. If you re-enter the ?Author data first you will rearrange author order. The solution is to use the structures

?Reference Author ?Author XREF Reference
 
?Author Reference ?Reference
If you are using sets to store order-sensitive data, avoid making links that cause rearrangements.

XREF chain reactions won't work

Finally, it may occur to you for some reason to try to set up a chain reaction involving XREFs:

?Silly Label_1 ?Silly XREF Label_2
       Label_2 ?Silly XREF Label_3
       Label_3 ?Silly
Falling further into deception, you enter the data:

Silly : "example a"
Label_1 "example b"
Unfortunately XREFs will not autopropagate in this fashion and you will not successfully target anything beyond the first XREFed field.

Show me the whole t-shirt model again.

Back to Table of Contents