An intractable problem using filters in a transaction?

[jjjjp]

I have switched to using transactions for the situation described below, and I am finding it impossible to maintain the full functionality that I had when I used to modify the children of a parent using multiple layouts, temporary records, and non-simultaneous commits.

 

Each workshop (parent) in my database consists of, among other things, team members (children). Team members can be assigned or unassigned. (So, too, can workshops, though this isn't all that relevant to this problem.) The user can choose to view and operate on workshops (maintained as a list view) in either an assigned mode or an unassigned mode. There is a global variable (let's call it ShowAssigned) that determines whether the user sees all workshops and team members, or only assigned ones. The list view for workshops changes to a different layout whenever the user toggles ShowAssigned. In order to allow the user to see which team members are associated with a workshop, I have created two text fields in the Workshops table, one contains a slash-delimited list of the assigned team members, and one a slash-delimited list of both the assigned and unassigned team members. Users see only the field appropriate to the mode they happen to be in (assigned only or all). 

 

The problem I'm having is with the implementation of a transaction for modifying the team members. A portal gets invoked with parent Workshop and children TeamMembers whenever the user clicks on a button for a specific workshop in the list of workshops. The user can commit only on exiting the transaction portal. The portal has a filter based on the global variable ShowAssigned, which ensures that only assigned team members show up if that global variable is set to 1. The problem arises when I need to update the two text strings showing the composition of the team members attached to the workshop. This happens just prior to committing all records and closing the transaction layout. To construct these two strings, I need to access the team members for both ShowAssigned = 1 and ShowAssigned = 0. Initially, the way I tried to do so was to calculate the string in the portal, then toggle the global variable, refresh the screen (without committing), and calculate the second of two text strings. But what I discovered is that the portal successfully toggles (shows all the changes in the alternate mode) if the user hasn't added or deleted any team members. If either of those operations has occurred, the portal remains frozen in its current state when the global is toggled and the window refreshed.

 

So what I tried instead was to create a second portal (invisible to the user) on the transaction layout, with the global variable in the filter toggled. Same basic problem. As soon as portal rows get added to or deleted from the first portal, the second one freezes up.

 

I am wondering if what I am trying to do is unrealizable with transactions. In other words, do I have to choose between (1) relying on non-simultaneous commits of all the changes to parent and children and (2) getting rid of the assigned/unassigned modes (which is a somewhat recent addition to my program and can probably be rolled back, painful as that would be given all of the work that went into it)? 

 

I illustrate both my attempts in the two attached (and compressed) files. I use a simplified parent/child model. (The two files don't implement the calculation of the two text strings. They aim to show only how the portals get frozen after certain basic operations.)

Archive.zip

DemoTransactionMethod1Expanded.fp7.zip

DemoTransactionMethod3.fp7.zip

[Wim Decorte]

I think you need to provide some more detailed instructions on how to create the effect you are seeing, in both those files.  I poked around a bit, did not see what you describe but very quickly got lost and then ran into a validation error.

 

Usually when I do transactions, I do the transaction completely in the background.  I don't let the user poke around while in "transaction mode" - too many chances of accidental commits, too much work to try and handle them all.  I collect the user's input, validate it and then run the transaction.

[Josh Ormond]

If you make changes and then clear or change the global, those records you edited or created are still sitting there waiting to be committed. There is no way for you to retrieve them again until you commit or revert.

 

If your functionality in the scripts or calcs are dependent on the values in those records...you can see some strange behavior. Including freezing of that portal.  I'd also stay away from refreshing the window without a commit while processing transactions unless you really understand what is happening in the background.

 

It is also beneficial to approach transactions as Wim pointed out. Keep the user out of the transactions themselves. It's similar to allowing the customer of a retail store to make their own sale and their own change while you go check on the server in the back.

[jjjjp]

Thanks Wim and Josh.

 

I agree completely about keeping the mechanics in the background. In fact, I am fastidious about never allowing an ID to flash on the screen for even a nanosecond. The demo I sent was not for users but simply for the Forum. I wanted only to show that what I was trying to do in the transaction wasn't working, and I wanted you to see the values of all of the global variables, etc. on a single layout. 

 

I've completely revamped my demo since your posts (see added attachment above) to give you a better idea of what I'm essentially trying to achieve, in particular to show (in drastically pared down form) what I want users to be able to see and do. The issue is getting the name listing to come out right as you toggle back and forth between showing assigned only and showing all. If you edit the team members for a workshop and add or delete a portal row in the transaction, the listing is almost sure to show up wrong when you toggle the value of "show only assigned" at the top of the workshop list. (You can correct it by editing the team members for the workshop a second time and clicking Accept.)

 

So do you think there is some other way to do this using transactions, or am I trying for something that I can't achieve within the constraints of transactions? In order to stick with transactions and simultaneous commits, I'm willing to convert all workshops and team members to "assigned." (Rather than un-assigning, the user would simply delete the workshops or team members; the only drawback is that they would remain in reserve.) But I want to make sure that I'm really at a dead end before undoing my past work. It is also instructive for me to understand the limitations of transactions.

[Josh Ormond]

Are you talking about flipping the view: After you Edit a Record, but Before you Commit? Your list will definitely appear correctly. You need to commit the change first, then flip the view/filter.

[jjjjp]

I'm talking about completing the calculation of the two text strings representing assigned team members and all team members before committing. To do that, I do need to flip the view after all of the editing by the user is completed but before committing. If I were to commit the records before calculating the second of two text strings, then my main reason for using a transaction would be defeated. I would no longer be able to ensure the integrity of what the user sees with 100% certainty. It is even theoretically possible (however unlikely it may be in practice) that the record will become blocked by another user between the commit and the calculation of the second string.

[Wim Decorte]

I would not use an unstored calc for this but set scripted.  That way you have full control instead of having to rely on FM's implicit behavior.

[jjjjp]

I am using a script to calculate the strings. I'm not sure a calculation would be at all possible in any case. The script is called CreateListing in the Demo I attached.

 

P.S. I can see that my language was misleading. I shouldn't have referred to the "calculation" of the strings. "Construction" would have been more accurate.

[jjjjp]

I was about to throw in the towel and accept that there is no way to do what I'm trying to do when what appears to be a viable solution came to me. Please see the third attached file, DemoTransactionMethod3.fp7. It divides the transaction into two portals. One shows only the assigned team members, the other shows only the unassigned. The string is constructed by going first to the portal on the left, and then to the portal on the right. There is no need to change a global field in the filter, and no need to refresh. The user doesn't actually see the second portal if he has toggled the global field to show assigned only. The ordering of the names (first assigned, then unassigned) in the longer string is different than it originally was supposed to be (all team members by creation date), but no matter. I think this new ordering is preferable.

 

This solution is similar to my second attempt (described in my first post), which involved two portals, the first showing all fields the second showing only assigned. That attempt, however, failed.

 

Thanks, Wim and Josh, for asking me to clarify my aims and to build a better demo. I'm not sure I would have figured this out without the dialogue.