Updated 11/24/2014 ( see below for whats changed )
Update 2/24/15 – Jason Young wrote a great blog post about using Selector Connector with Seedcode Complete.
Wasn’t this called Universal Context?
This is a video of what was the Universal Context presentation I gave at Pause on Error last month. The name however, had to go. It turns out that a “universal context” is only one of the features that kind of falls out of this graph architecture. So we busted one model into two and came up with a “Selector Model” and a “Connector Model”. I hope to put up something more definitive in the future, but I wanted to get this out quickly, because many nice people asked me to. 🙂
What Problem Does it Solve?
We started down this road to be able to make our complex solution simpler by building re-usable components. We didn’t want the graph sprawl that comes from having extra instances of TOs, and we didn’t want our scripts to get ridiculously complex because they need to handle different contexts. That was the aim of centralizing context. We wanted to write relatively simple code that worked from as many contexts as possible without causing undue graph sprawl.
Selector Connector does a pretty good job of meeting those goals. The really surprising thing for us was how simple some things got. 🙂
FileMaker Selector Connector Model
I am going to give a brief outline. For more detail, watch the video, or check out the example file below. For starters, these models are focused on how you build graphs for UI and scripting. Data level graphs might very well live in a different file if you are doing data separation. You could certainly build your data level relationships with this model. It’s just not what you’ll hear us focusing on.
There are really two separate concepts here. The fist one is the use of a single record, globals only Table/TO called “CONNECTOR” to connect everything together with cross join relationships. This is what creates the universal-ish context. The cross join makes it so your main table kind of share a context. Once you have that in place, a lot of stuff gets simpler. In the movie, I demonstrate several features that get rather simple once you put the “Connector” in place.
The second concept or pattern is the “Selector”. I know, it comes first in the name, “Selector Connector”, but that’s just because it sounds better than “Connector Selector” :-). It is a separate idea and could be used alone or in combination with a Session model quite well.
The “Selector” makes things Selectable. You “Select” records by setting global fields in the SELECTOR table occurrence. Those field are used are used as keys in relationships to each of the main tables in your system. If you want to select a customer record, you would use a set Set Field Step to set the “SELECTOR::_id_customer” field. (See how nice that reads?) That gives you access to that record through the “selected_Customer” TO. You can also use the Selector Model to create, edit, and even delete records.
FileMaker Relationship Graph Organization
In the end it all comes down to how you connect your Table Occurrences. Take a look at the image below. The CONNECTOR TO is on the left and the “SELECTOR” is directly to its right. The TOs outlined in yellow are where you build your Layouts. Up top in orange; those are utility tables. Notice how CONNECTOR is connected to all the other key TOs with an cross join. Thats the key. (You can click on the image to zoom in.)
Simple FileMaker
I’ll admit that at first I was wary of connecting everything together with the CONNECTOR. But once I did it, it became increasingly clear that it made a lot of things simpler. Things like graphic resource TOs, dynamic flexible navigation systems, Virtual Lists, pickers, and even DB Transactions just get easier. In the video I cover a lot of what gets easier in detail.
Whats the Catch?
So far we haven’t found any major problems. You will need to refresh the cross joins occasionally, much like you might have to refresh a window or an object sometimes. There is a script called, “Refresh xJoin” in the sample file that does the refresh for you. You also have to get used to seeing all the TOs being in one long list in some of the relationship selectors where they would otherwise be broken up into related and unrelated groups. This doesn’t bother me as it always showed up as one long list in scripts anyway.
At first it might seem like you end up with more TOs. than with other architectures. But some of these TOS are utility low record count Tables. Those are pretty cheap, and you only need one instance of each one, since it is connected to everything through CONNECTOR. Also regular data TOs will get re-used more effectively. For example you only need one selected_Customer TO for the whole graph. I think that in a complex system you will have less TOs in the long run.
Updates
11/24/2014 – fixed some errors and added comments to the “Refresh xJoin” script. This is a critical script so it is worth checking out.
Download
Please understand this is a demo file. The code here has been pulled out of customer code that we couldn’t share. Expect bugs and problems. But the key concepts should all be there.
Please let us now what you think. 🙂
Hi Todd,
in general, this is a nice idea and I’m using this approach for years now.
The only drawback I experienced is that opening and closing the database may get very slow when you have lots of TOs. This is due to the fact that all TOs will be calculated when displayed or when the file is closed.
pixi
Thanks for the comments.
Yeah as I say in the movie, is this really isn’t a new idea. Just maybe with a new twist or two. We haven’t yet experienced delays in opening and closing that are crazy long. But this is definitely an area that needs close scrutiny.
Thanks, Todd for sharing this technique and video. Great stuff! Re pixie’s comment, I wonder if the connector-selector approach doesn’t actually work in favor of improved opening times by reducing the total number of TOs on the graph (even if they’re more interconnected than in a strict A-B model)?
Of course, that interconnectedness means that each table now has a lot more “related” records through all those cross joins. But that, in and of itself, shouldn’t impact performance, given FM’s lazy loading of related data (i.e., related records’ data not fetched unless and until actually displayed on screen or otherwise used).
Will be interesting to see how this performs in larger (both in terms of number of tables [and TOs] and number of records in those tables) solutions, although I’m tentatively thinking it will scale very well.
Mark
Yeah some systems may endup with less TOs since we can re-use so many. We’ll see how it plays out over time.
Todd
I really like the sound of this method; I’m excited to start using it. There’s only one part I don’t understand…
Why use a separate table/table occurrence for SELECTOR and CONNECTOR? I can’t think of any technical reason for doing this. It seems to me like you could use a single table/occurrence and produce the same result.
My best guess is that it’s for logically separating the function these two features perform. Although in this case and with this example file, you could still use the same base table, even if you used separate table occurrences (since the SELECTOR table contains all the fields the CONNECTOR table has).
One word.
Modularity.
🙂
seriously though, CONNECTOR shouldn’t have nay fields other than xJoin, those other fields where left overs. I’ll remove them and re-upload.
SELECTOR and CONNECTOR are two different things. You could in theory use one without the other. So I put them in different tables. As I said in the post and in the movie, single record TOs are cheap. You get some nice organization and separation that way.
Todd
thanks for taking the time to do the video and example…
Really good starting point for some modular thinking.
john
Hello,
Thanks for sharing this.
I am new to filemaker so sorry if it is a stupid question.
In the beginning of your video, I was wondering why you are connecting the graphics table which has your logo in the relationship graph. I thought it was a global container field and you can access it everywhere with no connections at all.
I actually tried it on your file and it worked. I just think the GRAPHICS table example was not the best choice for the start of your video. Thanks again.
Hello,
Thanks for your comments. Your right if it is a Global you wouldn’t need to it this way. But storing Graphics in a global fields quickly becomes a problem when you are working with a FileMaker Server. You end up having to do a lot of work arounds to get consistent access to them.
Some people run a script on startup that transfers all of the graphics from a regular container to global container. Others load them into $$variables. All of these work-a-rounds require work.
The beautiful thing about this technique is that you don’t have to do any of those worka-rounds. It just works!
Thanks for sharing Todd (:
Great video. Thanks for sharing!
thank you !
I must say that was truly outstanding. I know that the main concept was to do with the “SelectorConnector” but there was so much more. Well done Todd – yet again – and thanks for sharing the awesome file that goes with the video.
One suggestion – Layout: Orders – in the Order_OrderItems portal you have accidentally hidden the trash icon. The trash icon currently has hide when IsEmpty( Order::_id).
Could I suggest all fields and icons in this portal have a hide based on – IsEmpty( Order_OrderItems::_id) – to hide the last empty row – both empty field formatting and icons?
Thanks for the nice comments. When we get around to cleaning up this example file further, we’ll take a look at incorporating your suggestions.
Thanks
Hey Todd, just curious where do you place your JoinTables? I understand to create a new join record that the join table be linked to the SELECTOR via the ID so it can be created. However do you link the SELECTOR parent ID to a foreign key to a duplicate TO off the SELECTOR table or do you place a TO to the foreign key as an buoy to the anchor?
I can see cases for doing it either way. I would probably have a TO hanging off Selector, anyway. As I want access to those records from other spots.
Make sense?
Todd
You are using global fields with a cross join. Wouldn’t using a stored calc field with a 1 in it and a normal join do the same thing? Would there be a down side that I am not thinking of? I’m asking because I already have such a field in most of my tables already.
They need to be Globals, because you need to trigger the relationships to refresh by setting those fields. So they can’t be Global Calcs. See the “Refresh xJoin” script.
hth,
t
I am really excited to try using the Selector Connector concept. I have a solution that is not real large, but will be growing. I would welcome your thoughts on “retro-fitting” an existing solution with Selector Connector. I still have trouble getting my head around cross joins (cartesian product), but this helps quite a bit with understanding how they can be used. Thank you.
Great stuff Todd. I really love how much DRYer this makes everything, and how clean this makes name spacing as well.
As Pee Wee Hermann once said, “Everyone has a Big But”. Here’s mine 🙂
As far as I can see, this technique as defined so far strongly implies we’re choosing a single document interface (SDI). As long we limit our UI’s within a session (or entity-session, depending on how we wire specific SELECTOR / CONNECTOR globals) to a single window, everything’s golden.
But what if we open a second/third/nth window for the same entity? A “flat” global can’t do different things for multiple windows simultaneously. So say we’re using a virtual list-based picker for a customer in window 1, and while that’s still open, we try to use a picker for a product in window 2. Or say we’re viewing SELECTOR-based portal records in for a customer in window 1 and switch to another window to view customer records for the same portal. Channeling everything through a single-valued global might bite us in cases like these.
I don’t see this as a fault or problem at all. But I do think it’s worth calling this out. The good news is that we have several options for dealing with this:
In many (most?) cases, we can simply disallow multiple windows, and there’s no issue.
Where we do want to allow multiple parallel windows to be open, we might either:
– make the globals in SELECTOR / CONNECTOR repeating fields. We’d could couple this with something like a windowContexts list designed to let us “thread” each window to its own set of globals, and from there to a window-specific set of related SELECTOR / CONNECTOR records. Or,
– simpler: perhaps consider adding something like a currentContext global in your model, then add tests where unexpected context (window) changes might bite us.
Bottom line, though: This is brilliant work, and opens up a ton of possibilities for our community. I’m looking forward to seeing how this impacts our development practices. Thanks for this 🙂
Thanks Brian!
Your right multiple windows won’t work. But this isn’t really a problem with this model specifically. Multiple windows make a whole bunch of things more difficult or impossible. Virtual Lists won’t work, session models won’t work. Any UIs that use global fields or global $$Variables don’t work. So this is a critique is whole bunch of techniques not just SELECTOR CONNECTOR.
I have tried variations on your suggestions over the years. I used to try to name space my variables based on the current window name. Or I used repeating globals. Or even a session record per window. In the end I found it to be far from worth it.
Besides, multiple separate windows is a dubious UI pattern in the first place. Its an un organized mess of windows stacked willy nilly all over the place. And increases the likelihood of record locking.
So I happily punted on it several years ago. And I never looked back. 🙂 Occasionally it comes up when somebody needs to see two records at the same time. But that can be solved quite easily with out resorting to multiple windows.
The honest truth is I don’t even consider multiple windows as an option, so I forget to mention it as something that others might want to do. So thanks for pointing it out. 🙂
But’ll still go back to my default answer which is “Don’t do it” 🙂
Thank you, Todd, for sharing this method and modular code model. For years, I’ve looked for simpler structures in Filemaker for doing just this – a clear and succinct functional TOG with single or limited TO’s.
I’ve been developing an entities|graph model for relationships for a while, and attempting to implement in Filemaker using a similar concept of the ‘connector’ – a dedicated Entities table, or ‘one ring’ approach that has been challenged by the problems you’ve addressed with this model. Where I have equivalent relations to this dedicated table
http://note.io/1CM3Ksw
the cross-join connector will allow for data to stay ‘in place’ in their dedicated tables, and for me to develop out a single system for attributes that can work throughout the solution. This is awesome.
Many thanks. I’ll report back later when implemented.
Michael Ashley
Awesome glad you like it 🙂
Thanks Todd, its a great model.
One thing I am finding is that when I try to create a series of new records one after another using the ‘magic key’ technique (with the global keys now inevitably residing in the SELECTOR table), I clear the global, create the first related record which works as expected. However, when I clear the global again in preparation for creating another record, the relationship to the first record that I created persists. I have to ‘Refresh X-Join’ after I clear the global again in order to make another new record.
Previously when using ‘magic key’ transactions (where the related table was only relationship away from the current table), I could just clear the global, set a related field, clear the global, set the related field repeatedly to make multiple new records. I presume the difference is to do with the related table now being 3 steps away (as in MYTABLE–>CONNECTOR–>SELECTOR–>TARGET TABLE) – it no longer reliably refreshes/destroys the relationship when you clear the global.
It’s not necessarily a problem, but one to watch out for.
Andy Smith
Hi Andy,
You are right. When I first hit that problem, I was very bummed out. I thought it would destroy the whole idea. However the fix is easy, as you point out. If you look in the Sample file you will see a script called Refresh XJoin, which was written for exactly this purpose. It will refresh the xJoins for you.
There are a few other things you have to do differently. For example if you try to create a record through MYTABLE–>CONNECTOR–>SELECTOR–>TARGET TABLE and you have no records in the table or no records in the found, it won’t work. You need to have a record for that to work. What I do in that is go to a special SESSION layout that has a record for me to work with, and then come back.
Todd
Hey Andy and Todd,
I just experienced this problem myself, when trying to create multiple new records via magic-key, using the Selector structure. And as Todd pointed out, you can fix it by running the ‘Refresh XJoin’ script.
I did a bit of testing, though, and found that all you had to do was set the field on the upstream side of the x-join relationship. It didn’t appear to be necessary to set the fields on both sides. E.g. if you have TableA::xjoin = 1, Selector::xjoin=1, and your relationship is TableA::xjoin [X] Selector::xjoin, then all I had to do was set TableA::Xjoin = 1 again in the script with a single ‘set field’ command. Just setting the single field on the Selector side didn’t work.
Sticks in my mind that I have used magic-key to create multiple records in the past, and not needed the refresh xjoin trick. But, that was with ‘equals’ relations (‘=’) and not Cartesian ones (‘X’).
Is this an example of the same problem that seems to plague the refreshment of portals or of global variables shown on layouts? These are always frustrating items to run into, having to do a bit of extra leg work to get these capabilities to work.
— Justin
Hi Todd
I can’t tell if this is due to SelectorConnector or just MasterDetail, but how is one supposed to Find a Customer? Doing a find for “pigment” — either via Find Mode in the companyName field or via the zg_QuickFind field — returns the initial found set of 200 records & current record at “Pheasant Diggers”, instead of the 2 records containing “pigment”.
(Also, in case you ever do rebuild this file, the “Edit Item” button per Order needs to set the $$Pr (portal row) variable)
Thanks,
John
Hi John,
There is a bug in the script “Virtual Trigger: Run Before Virtualizing the Found Set”. Remove the Show All Records at the top of the script.
I will update the sample file.
Thanks for pointing this out.
Todd
Thanks for sharing your technique. I have looked at your demo file and I understand the basic concept but I am trying to get a little better handle on how to expand the solution.
If you wanted to show a portal on the customer’s record that shows their orders would you create a new TO in the SELECTOR section (for example, ‘selected_customer_Orders’) that connects the customer to the orders based on the customer_id or would you use some sort of virtual list to display this information?
Hi,
I probably wouldn’t do a virtual list in this scenario. I might create a new TO in the SELECTOR section, if this was something I wanted to have available from more then just a customer TO. But I would probably first just go ahead and hang a Customer_Orders TO right off the Customer TO. Thats the simplest thing
The good news is that SELECTOR CONNECTOR can do all those things. And they all might make sense in different scenarios. Your not locked in. The bad news is that you have to make a decision about what to do, and OMG what if you might make the wrong one !!! 🙂
Get used to it. Uncertainty is in at the very core of software development. 🙂
The best you can do is have a flexible architecture that doesn’t box you in. We think SELECTOR CONNECTOR is pretty good at that.
Hope that helps.
Todd
Thanks for your reply Todd.
I’ve been using a system similar to this for while – but the Selector/Connector fields were in a User table – storing the selector state at the end of each session for each user. But no big deal storing the state in a SEPARATE user table.
In the “Refresh XJoin” script in your sample file, you note that you forgot why the join fields in the local table, not just the SELECTOR and CONNECTOR tables, need to be toggled. I had forgotten myself, but I ran into the reason again today. You can’t create multiple related records in a single transaction through the SELECTOR relationship without touching the local field. You noted above that the “Refresh XJoin” script resolves the issue, but not the specific dependency on touching both sides of the relationship.
I also found that it isn’t specifically necessary to toggle each join field between empty and 1. Each field only needs to be edited once, which I’m accomplishing with “not [Self]”. https://www.dropbox.com/s/ihl5gq15mp95ml6/Refresh%20Selector%20Connector%20Relationships.pdf?dl=0
Update: Apparently, editing the local join field is the *only* part that’s necessary. I tried not editing the SELECTOR or CONNECTOR join fields in the refresh script, and everything still seems to work. Nifty! https://www.dropbox.com/s/ihl5gq15mp95ml6/Refresh%20Selector%20Connector%20Relationships.pdf?dl=0
Jason Young is of the same opinion as you are about this having to kick only the local field. I am pretty sure that I ran into scenarios where it wasn’t enough. So my refresh xJoin scripts hits them all.
Your right that it only needs to be edited once, I simply wanted them to always be “1”. So I cleared it and then set it back to one.
jBante, your tip can be critical to maintain the transaction. The included ‘Refresh xJoin’ script won’t do the trick if your TO-chain is longer than the simple ABC -> Selector.
I ran into this trying to create multiple new records in one transaction from 4 tables away (LineItems -> Revisions -> Quotes -> Selector -> selected_LineItem); it would work on the first record but not on the second record. I must have forgotten your handy response here, because I was stumped as to why the ‘Refresh xJoin’ wasn’t working. I did some testing and eventually figure out that resetting the local field (i.e. the first field in the relationship chain) was all that was needed – but you had already figured it out! I wish I had a better memory – it would have saved me lots of time and stress. 🙂
— Justin
Todd,
Loving this outside the box thinking! One thing that we have noticed in our implementation (and in your sample file) is that related images disappear in Find Mode. Was hoping to get away from our old method of setting global image fields on startup, but may need to stick with that for some things. Or change to storing images in the theme/style… but that way doesn’t allow users without layout access to make updates/changes… which of course can be a pro or a con, depending on the business logic.
Just curious if you had noticed this, or had a work-around. Thanks for all you share!
-Shawn A. Krueger
Hi Shawn,
Thanks for the comments. Yeah, I tend to use Quick Find more then Find Mode these days, but yes in find mode this will be an issue. I guess I am not to concerned about it. More and more graphics are moving to the theme, any way. And if I really had to have images in Find Mode for a given screen I can do the globals thing for just the stuff I need for that screen. That is the exception rather than the rule these days.
🙂
Todd
Hey Todd,
I just implemented Selector Connector for the first time and it is wonderful. It makes life much easier! Thanks so much for your insight and for sharing with the community!
Thanks Kristy!!!
Todd
Hey Todd,
Great article. As noted in the comments for your Transaction module, it helped me figure out a problem I was having with creating related and sub-related record (i.e. 3 layers of records: parent, child, grandchild).
Something additional I was reading in Jason’s blog post about this technique and I wanted to reflect here: if you want to ‘select’ multiple records (perhaps preceding a GTRR command) you can do that by putting in a list of IDs into the Selector field for whatever target table you are concerned with.
Thanks again,
Justin
Thanks Justin!
Love the concept, trying to work through the logic, got stumped right off the bat. How is the Button: Menu script that calls the Navigate To script executed that selects the various menu layouts? Can’t seem to find any elements that execute the script. I see the Button: Menu script executing when I run the script debugger, but can’t find on the layout anywhere.
Thank you
Al
Hi Al
Its right there in the portal.
See this image
https://www.evernote.com/l/AAJrgZIa-RJLtZRmJQmFytAFQ_GPchgd8b8
Todd
I get the dialog box with the message “The selected group of objects includes at least one previously defined button and therefore cannot be defined as a new button.” if I click on the portal, but there is no Action showing to perform a script, The only badge I see is the Conditional Formatting triangle on the blue rectangle, no button badge. I am using FM 13, in case that makes a difference. Thanks for the help.
Sorry, it isn’t the Conditional Formatting I can see but the Hide Condition badge that shows in the first portal.
Todd,
I watched this with an eye to seeing if you had come up with anything different in regard to deleting records without changing context. You didn’t go into much detail other than mentioning that you need a portal on your layout, so I thought I’d mention the context of a Deleter table. The table would probably hang off your Selector ( that’s how I did it ) and is set up similarly to the Selector. It has selector fields for each table you’ll need to delete records from, but it also has a UUID field. The relationship from the Deleter to the TOs you’re deleting from are set up with Cascading deletes instead of Create through the relationship.
All you need on your layout is 1 portal to the deleter table and you can delete in any table. You just create your deleter record, set the selector keys for the records you need to delete, and then delete the portal row in the deleter table.
This is not needed if you’re only deleting from one table this way, but if you have multiple child/grandchild tables you need to delete from, you only have to place one object on your layout to do it. You can set selector keys to multiple tables at once, and even drop in a list of keys, thereby allowing deletion of hundreds of records in multiple tables by deleting one record from a portal. You probably already thought of this, but in case you haven’t I’m throwing it out there.
Thanks for the excellent ideas,
-jb
Hi Jb,
This sounds like a good idea. Can you do it with in the context of a single transaction? In other words can you be creating or editing record in other tables and then delete records using this method and then commit everything at once? That would be very cool!
Todd
I see on your Relationship graph that you have ‘no layouts’ surrounding the Selector connections. Why is this?
Thank you.
Pat
Hi Pat,
You don’t ever want to be build layouts on the SELECTOR and CONNECTOR Table Occurrences because you want to make sure those records can’t ever be locked. Since all users share the same single record in SELECTOR and CONNECTOR if one of them should become locked, the entire system will fail.
If you all fields in those tables are GLOBALS and their no Layouts built on them, then the records can’t ever be locked.
Hope that helps.
Todd
How do I create and delete records in a MasterDetail structure?
I believe this will require both repopulating the Rows table, as well as refreshing the portal
But I can’t figure out how to do it
Jill Wellman
Hi Jill,
Any time you change the found set, which deleting would do, you need to run the Virtualize Found Set script. That will handle everything for you
Hope that helps
Thanks
Todd
Hi Todd, great technique and great video. I am trying to digest all the information, but the zip file seems to don’t work, could you please fix it up? Thank you for your great contribution to the filemaker community. Maria
Hi Maria,
Can you tell me what about the zip file doesn’t work? I can’t seem to find anything wrong with it.
Thanks
Todd
I have encountered an significant error that I can’t figure out. The Picker can’t select words that contains accents, in our case in the spanish language.
The problem is with the ExecuteSQL, it differentiates from characters with and without so you have to type the word with the accent if you want to find that word. The problem is that users usually don’t use accents when searching.
I can’t figure out how to solve this issue.
Any ideas?
You may want to create field calculations that remove the accents from those fields and then use those calcs in the SQL
That’s about the best I can come up with
Todd
That’s what I did, only text fields with auto enter. I am surprised because it this differentiation doesn’t happen when we program Web with PHP and MYSQL
Hi, Todd, I have followed a lot about your technique, as you said somewhere it takes some time to get use to it, great design and love the experience since I implemented it, One major advantage in combination with “Transactions” it has reduced me a lot of work. Yet don’t think I have fully understand the whole picture.
I notice on the Demo file that Transactions are not been used for all situations, I guess is just in this demo file, In my solution I tend to Lock every action in the current layout adding, editing, deleting until save or revert. In combination with portals this is super easy, nice and smooth, but there are times when I need to add records and not use portals or PopOvers on portals to add, for this I´m trying with the Magic key technique. This is where I´m stuck, I can not “Add” new child records to a related table except for the first one until I commit the parent record, I have to commit and then clear the magic key field in this case SELECTOR::GLOBALFIELD_ID and now is ready to add a new child record, but the problem is that I´m obligated to commit and then I loose the ability to Revert, Also if I place a Portal (same related table) just to viewing the list of childs while adding, it won’t show the items until Committed. Is this the way it supposed to work? I believe I´m doing something very wrong or missed a step or two somewhere.
Greatly appreciate any help.
Thanks in advance,
Fernando A.
Look at the Refresh XJoin Script. Try calling that after you clear GLOBAFIELD_ID to get ready for creating a new record.
Todd
Thanks for taking the time and the advice, I was using the Refresh Xjoin script short version jajajajaaja, neglected the whole part that says “This section may not be necessary” my mistake for assuming and omitting it. I can confirm that by running the complete XJoin Script “Adding” new child records using Magic Key its now funcional!!!! …
YESSS..,
Yet, I cannot confirm the same for “Displaying” the newly created child records. The Portal related to the parent (used only as view) won’t display anything until the parent record has been committed at which time they appear all at once in the Portal, thus suggesting a false illusion that the child records are not been really inserted.
Don’t know if this makes any sense. I tried XJoin script before and after plus some other things that I thought could resolve with no luck.
Thank you once again,
Fernando A.