Indexing and Storing troubleshooting

[ESpringer]

My task: This bibliographic database has many self-join relations: A&B share author; A includes B; B includes A; A&B are included in the same anthology C, etc. I would like portal hotlinks from each record to others related in *any* of these ways. But if I were to create four separate portals, they'd waste space: each of the four would need to allow for 20 rows, even though in most cases related records would pile into only one of those portals. So I've been aiming for a "disjunctive relation" to enable an inclusive 25-row portal from A to Bs of all these related kinds.

What I did: For each relation I made a Value List of related ID#s, and then with one calculation field concatenated those Value Lists into a long paragraph-delimited list of all those ID#s for which *this one* should show up as a related record (and vice versa, given symmetry of this set of relations). The ListConcat basically looks OK and seems to function as a RH key: I can build a portal on it. BUT it doesn't update when I add new records.

Clue: When Fenton first pointed out to me how to calculate using Value Lists to create tweaked relational keys (thanks!! ), he mentioned that the right-hand list calc field must be set to "Do not store...". I suspect this is my problem. I *did* turn on storage. But that's because (1) FMP told me this relation (between master record's ID and IDs found in the ListConcat) wouldn't work because that field couldn't be indexed, and (2) when I made the relation anyway, *nothing at all* showed up in my portal as long as storage was off. (The concatenated value list, if I put in on a layout, looks fine though). Hitting the Indexing always On radio button doesn't seem to affect the situation...

It's hard to believe it can't work: I've been back and forth several times. Whenever I turn storage off, ListConcat updates nicely but portal is empty; when I allow storage on, the list freezes but the portals work perfectly based on what's there.

Is this enough detail to recognize what I'm missing?

[Fenton]

It's the left side that must be Unstored, not the right (did I say right? It's possible; many's the slip...). The right would have to be a return-delimited concatenation of whatever you'd want to match, stored.

[ESpringer]

Indeed, the right side is stored as return-delimited concat calculation from the various lists...

Left side is not a calculation at all -- just the straight ID# tag.

so, hmm... any thoughts about why concat list wouldn't be updating when I add new records?

The individual Value Lists do seem to be updating (if I attach pop-up to a field, say) just not the concatenated one... which does work fine as RH key for the values that ARE in it... ??

[Fenton]

You're using "ValueListItems," right? They will not update unless they're unstored. Otherwise we'd have true indexing across relationships; which would be wonderful, but is not currently supported.

Is it possible to do the opposite of what you're doing, ie., put the ID# on the right? I don't know exactly what you're dealing with, I don't know what A and B are. It always takes me awhile to see what someone else is doing.

[Ugo DI LUCA]

When adding new record, try to add a "Exit Record" step, as it sounds your key is based upon multiple self-joins or concanated Value List Items.

HTH

[Ugo DI LUCA]

Agreed Fenton !

It's not clear why you have stored value list at right and an index tag at left...

The opposite would make more sense but then it just depend upon what exactly A and B are and what exactly you are doing with this tag#.

Huh ?

[Fenton]

It sounds like what you need on the right side is a return-delimited concatenation of the IDs.

So it would look like:

AuthorIDs & "

[ESpringer]

Thanks for the replies, Fenton and Ugo! I am now reversing the keys, so that LH is the ListConcat, RH is ID tag. Now, if I understand, ListConcat can stay unstored and flexible, without breaking relation... calculating 3000 records... Eureka, it works!

(If you're wondering why I didn't do this before -- I had been enlightened only recently, by Fenton, that relations could "see into" return-delimited fields as multiple entries, and somehow had assumed (because it was that way in the example file, and/or because I was rigidly thinking "one-master-to-many-related") that they would do this better with the list on the RH side. Just an assumption. Glad it was wrong!)

By the way, just in case it's helpful to anyone wanting to make sense of what I was up to, here's a bit of a screenshot of portal. I don't have to worry about WHICH records come from which relation, because the basic idea is just to provide a sort of neural net of helpful hot-links (ID# is button), color-coded and sorted by reference type. So, if I'm looking at something Dewey wrote for the 20th Century Ethical Theory anthology, the portal at the bottom shows same-author monographs (reddish), relevant enclosing anthology (grey), same-author article(s) (green), any-author peer-contributions to this anthology (tan) as well as any records for other book chapters by this author (tan):

And here's the calc field for the left key:

Substitute(Substitute(

"

[Fenton]

Looks good. I don't think you really need to remove the extra carriage returns.

See you all in the morning.

[Ugo DI LUCA]

Hi,

Now, what I understand is still a limitation is: Suppose I had return-delimited key-words field ... I couldn't make a properly-updating relation that connects THIS record with the full set of records-that-share-ANY-keyword, because the relations wouldn't be able to update if values were stored, and values wouldn't be able to support relation if unstored. Yes? That would indeed be a nice limitation to overcome!

You can have return-delimited Left key matching a return-delimited Right key.

Is it what you are after ?

IMO, the only limitation, which could be solved by a script (with a loop) though would be to perfom an AND match rather than a OR, and even more tedious a strict ONLY match.