I have a cascading portal arrangement that I am trying to work with FM transactions and the selector connector model proposed by Geist Interactive.
The data structure is pretty simple:
aManufacturer -< aType -< aVar -< jointAEVariants >-eVariants >- eType >- eManufacturer
The user gets on the layout and selects a value from the aManufacturer table in a portal. When he clicks the button at the end of the row, it sets the UUID value of that related record into a global field of the selector table to show only the related aType table entries. The relationship for this specificly is as follow:
selector -< aType - selector::_kpgn__aManufacturer = aType::_kfln__aManufacturer
The user then keeps going until he narrows down his search to a value in the joint table. This all works fine until the user starts adding types or variants without committing records in between. If a user adds a type to a specific manufacturer, it basically freezes up the portal until I commit records. No matter which Manufacturer entry I choose and what global field value I set for the manufacturer field of the selector table, I always get the same values as when I first created a new type or a new variant entry.
Obviously, if I commit records, the portals will end up with the correct information displaying and sorted as required. However, since this layout is used for all sort of other data entry and the manufacturer/type/variant creation is taking place inside a pop-over, I would like to maintain the transaction philosophy and avoid committing the records until the user presses a save button that is somewhere else on the layout, to also give him the possibility to revert records if he wishes to.
I also tried using executeSQL to find all the related records UUID and make myself a "list" in the selector global field to extract all the related records and display them in a portal. The executeSQL function actually manages to find uncommitted records that bare the foreign key I am looking for, but the portal refuses to display them until the records are actually committed. The only way I was successful in displaying uncommitted information in a portal without getting any problems was to use a Cartesian join with a portal filter.
However, as this database is going to be shared, I'd like to avoid the Cartesian join thing to try the related records to what is really required for the data the user is trying to see and prevent downloading useless records.
I have also tried combining a Cartesian join and the global - foreign key relationship together to force a refresh of the relationship. However, doing this, I can't see the newly added records until I commit the changes, even though the entry lists the correct foreign key and is even able to show the manufacturer description, meaning that the join between the table works. The problem here really seems to be the way the portal behaves...
I am not sure my post is clear, I have a hard time explaining it, but hopefully somebody can figure out what I'm trying to say! The snip of the relationship diagram is only a quicly made copy of the real thing, so don't look at the names and all that!