Don't know if anyone else has run across this issue. I reported it as a bug, but maybe I'm missing something.

Anyway, I have two tables (T1 and T2) and a join table (Jt). All relationships are by keys. JT records are created from T1, and the T2 key is looked up via a secondary relationship based on a global text field in the join table. (T2 key is looked up based on a text value put into a global field in the JT portal row. See attached .pdf. Global text fieldin JT is via a conditional pop-up list based on text values in T2.)

This is all quite normal stuff so far.

Unfortunately, when I'm creating new records, instead of looking up the T2 key, the primary key for the JT is substituted. (E.g., if I'm creating new records and I have a pop-up list with four values, I expect the corresponding T2 key to be looked up based on the chosen value. Instead, the primary key value for the new JT record is put into the T2Key field.)

However, if I select a new global value in an already-created related record, the correct T2Key is looked up and put into its proper spot. So, new related record = bad; changed related record = good.

One other factor is that all of my primary keys are based on a calculation that determines the highest existing key value and adding 1. This seems to have caused some problems in FM7 rev 1, but that specific problem disappeared with v2. Don't know if this is another odd case.

Anyone had issues like this? Thanks for any input.

Strange Portal Behavior.pdf.zip

I cannot follow exactly your example, but I have experienced similar problems, and they occur when a key cannot be accurately indexed. I would suggested going to define field, select options, turn indexing on and make sure FMP is able to index your keys. This is very important if a key happens to be a calculated field, such as name & SSN etc.

Yes, I suppose that was a bit confusing, and the pdf was probably of little help.

I'm attaching a new FM7 file to demonstrate what I'm talking about.

BadPortalEntry.fp7.zip