1 2 Previous Next 15 Replies Latest reply on Feb 8, 2013 2:37 AM by FileKraft

    sorting and filtering in "transactional" portals don't work


      setting the relationship to allow creation of related records breaks portal-filtering and portal-sorting as soon as you enter a new line.


      this is very unfortunate - since sorting reliably works even if records in that portal have been opened but as soon as you

      add a new line (at the end of the portal) the portal is frozen to the sort before the line has been added.


      regarding filtering as soon as one of the records in the portals has been altered (opened) the filter only kicks in as soon as

      all records are saved (recordOpenCount =0).


      i consider this a major bug/limitation because filtering and sorting stop working as soon as a new line has been legally created thru the portal

      and portals are the only way to implement transaction processing over child-records.


      please FMI fix it.

        • 1. Re: sorting and filtering in "transactional" portals don't work

          Portals are not the only way to do transactional processing on child records. You can also modify and create related child records one at a time from the parent context via a utility relationship from special purpose key fields in the parent record. Just set different values to the Parent::id_Utility field to "select" each child record as you work on it, rather than scanning through portal rows. If you need to transactionally create multiple child records via a create relationship, you can set the Parent::id_Utility field with a new UUID then set fields in the child table for each child record you need to create, and this will work transactionally, too.

          • 2. Re: sorting and filtering in "transactional" portals don't work

            Thanx for your input. Unfortunately that hits me again with the same limitations. I cannot filter or sort a related set of created records and not even revisit a once uncommited newly created child record.


            Filtered portals are just unfinished develpment becuase they only work if all viewed records are saved. I hope i can be proofed wrong but right now that's what i got stuck with.


            [please FMinc fix this. as well as portal sorting]

            • 3. Re: sorting and filtering in "transactional" portals don't work

              ExecuteSQL works to filter and sort related sets of created records. I concede that a created child record cannot be reselected until after being committed — I wish I could, but I can understand why FileMaker may not do that at the moment (timing of index entry creation and whatnot).


              I can similarly understand why portal sorting and filtering work the way they do. Performance is important and "touchy" for both. The only real way to make computer software faster is to ask the computer to do less on one level or another, since hardware performance is approximately a physical constant. I imagine portal sorting and filtering may only be triggered by certain events as a way of asking the computer to do less. I further imagine that someone may have chosen portal sorting and filtering (and indexing) to be triggered on commits and not on record modifications. It's not always convenient, but I'm happy to make that tradeoff for the sake of a responsive user interface. I doubt that the current behavior is a bug.


              When I'm writing a solution to use transactional processing, I'm generally doing that processing via script without involving the end user. I think of portal filtering and sorting as stricting UI-centric features. Transactional processing is a more developer-centric under-the-hood idea, and I'd rather have developer-centric ways to accomplish it. Admittedly, programming via the UI is a huge part of FileMaker's shtick, but we all know that only goes so far. I'd be happy with the ability to re-select a created child record before committing the transaction.

              • 4. Re: sorting and filtering in "transactional" portals don't work

                i disagree - it is a bug - because  a lot of functions fail just by turning on filtering - even if you use a predicate which stays silent (doesn't filter the selection) - the getnthrecord function for example - list function etc .. and if you uncheck that filter box it works again as expected. {you might call this a feature though )


                {easy to proof in the data viewer)

                • 5. Re: sorting and filtering in "transactional" portals don't work

                  The GetNthRecord and List functions act on data available through a relationship, not on what's visible in a portal. They never have, really, but the introduction of portal filtering also introduced a new distinction between what data are available and what data are displayed in the user interface. Portal filtering is a UI feature, and the GetNthRecord and List functions just don't act through the UI.


                  Nor should they, necessarily. If I had two portals to the same table occurrence on the current layout with different filters, which should the GetNthRecord function use? Using the underlying relationship instead of the portals gets the most consistent and predictable results. We might say that these functions act on whichever portal is active, and the underlying relationship when there is no active portal; but now the behavior of these functions is more complicated and code using them will be more difficult to understand and debug — the less state we have to think about, the better.


                  If you want to GetNthRecord or List results that respect a filter, just use ExecuteSQL.

                  • 6. Re: sorting and filtering in "transactional" portals don't work

                    the less state we have to think  ... that's exactly what i am trying to explain - why does it fail - just by activating the filters - or why does sorting break if one child record has recordOpenState 1 (created thru portal)  - and all worked before if record open state is 0 or 2 within the portal ..  - and SQL won\t help me out here .. again prroof me wrong - so far i am not convinced. thanx for your efforts though. very glad about your input.

                    • 7. Re: sorting and filtering in "transactional" portals don't work

                      It sounds to me like the issue is not that these feature fail to do what they were designed to do, but that the designed behavior fails to agree with your expectation. In the name of performance, portal filters and sorts only update in response to certain events, perhaps fewer events now in 12 than in 11. (Or so I guess. I'm sure we'd all appreciate any inside scoop on that decision.) GetNthRecord and List have never respect sorts and filters set in portals.


                      Perhaps I and others can suggest more helpful ideas if you tell us what you're trying to accomplish in more specific detail, which might also illuminate why my suggestions so far wouldn't work for the particular solution you're building.

                      • 8. Re: sorting and filtering in "transactional" portals don't work

                        i want to accomplish - creating related records in a portal without committing until all entered (or offer to revert parent and child-records) - then for some line items i want a toggle to collapse and uncollapse grouped child records.


                        this is easy to do if i don't allow creation of related records (non-transactional version). since this has to be transactional - with a save and undo button for committing or reverting explicitly - the only way i think this could be achieved is using the portal filter to suppress the records if the toggle is closed etc ..


                        thanx again for the feedback - very much appreciated!

                        • 9. Re: sorting and filtering in "transactional" portals don't work

                          I sometimes create one relationship used only for creating records via portal. Other relationships and portals can be used for viewing and editing.

                          • 10. Re: sorting and filtering in "transactional" portals don't work

                            You might consider using a script trigger or button that opens a pop-up window.  Have the user enter the data in the window with buttons/scripts to save and cancel the operation.  Not as simple as creating records in the portal but it gives you more control and lets you confirm that all of the required fields are filled in.



                            • 11. Re: sorting and filtering in "transactional" portals don't work

                              thanx Bruce for your suggestion - i already explored this - but i am losing the transactional connection between parent and child-records within the portal if opening a new window.

                              all validaiton etc happens very reliably in the portal though and the user can tab

                              • 12. Re: sorting and filtering in "transactional" portals don't work

                                Hi FileKraft


                                I made a demo file, which I wanted to send to you - until I came across the very problem that you are facing!


                                You can't make a new record, in the layout with the Portal, without saving a record.


                                So I approached the problem a different way (this time only in theory! - sorry)


                                Could you have a resource of new but unallocated child records.  These could be showing in a portal of new (available) records.  Various entries could be made directly into these child records, for example setting the foreign keys, Sort keys etc.  Changes could be made to any number of these child records and they would not be saved until the master record was committed. But they would respond to the sort order of the portal. Or the changes could be reverted - setting these records back to their unallocated state.


                                I accept that having sufficient records ready to start with, is an issue, but these could be generated following the saving of the previous set of records - providing a static number of unallocated records.


                                I hope I've made myself clear!


                                Best wishes - Alan Stirling, London, UK.

                                1 of 1 people found this helpful
                                • 13. Re: sorting and filtering in "transactional" portals don't work

                                  One things to possibly try is to add an OnValidate script trigger to key fields in the portal.  This script trigger does let you revert the record.



                                  • 14. Re: sorting and filtering in "transactional" portals don't work

                                    Thank you very much Alan, you really got the situation right. And thank you for confirming the "issue". What you suggest using in advance created records and assigning them with the matching keys on the fly - it doesn't work - they only show up within the portal on commit - so they are not available for data entry. which actually makes sense and i am not complaining about it. I also tried with pre-loading empty lines into the portal but that breaks a lot of things in the logic and slows down overall interaction with the solution.


                                    Thanx again. Great ideas.

                                    1 2 Previous Next