Given what you described, you need to show all records from "table B" on a layout from "table A", just use a cartesian join. Select the "X" operator in your relationship between any fields, no calcs needed.
If you're trying to constrain by a user's records in a relationship, then you need a global field in "table A" that stores the account name, then relate that to a stored value in table B of which user that record belongs to. Like creation account name or modification account name.
Your relationship as you've tried to establish it is invalid (unstored calc related to another unstored calc), so it's throwing you the "unrelated table" error.
Thank you for input. Correction to my previous setup as I work thru. Table 1 is a single record with the calc to text get(accountName). I am looking to create relationship with table 2 whos field matches but not contained in every record, so this would be a 1 to many. Note, table is not a calc field as all records will not associate, but concept is the same. Is your solution the same?
Is the calc field set to store as global in TableA ?
You cannot build a relationship that references an unstored calc on the "to" side.
no I have this field set up under indexing as "Do not store calculation results" so that the next person who signs on will not filter the same results.
As keywords just aptly explained, you can't use an unstored calc on the "one" side of a one-to-many relationship.
You need to store that. Change it to a global storage text field, and add something to your login script that sets the value of that global with a calc of Get(AccountName).
This should allow the relationship to become valid.
I did notice a potential problem. Thru the manage db, the table with 1 record, actually show 0 records. The import of another file worked to the extent that it brought in the 5 fields.
When I try importing alternate files in this manor with many records, the fields transfer but not the records. Is there a setting that requires adjustment?