7 Replies Latest reply on Sep 7, 2012 12:26 PM by Stephen Huston

    FM 12 - Severe bug in portal rows ?

    intex

      Hi at all,

      we are building new databases with FM12 in which we have portals for choosing records for editing, marking and deleting. There are buttons on each row for record deletion. This is scripted to have a different dialogue telling the user that he will delete a "record", not a "related record" which can be confusing.

      Now the problem - we can delete let´s say 10, 20 or 30 records without any problem. But then we get error 101 - record not found. From then on we can´t delete any record in the portal. If we then go to the related record via the portal and return back, we can delete again. What the hell is this ?

       

      Thanks for help

       

       

      Martin

        • 1. Re: FM 12 - Severe bug in portal rows ?
          intex

          Guess, we solved it.

           

          FileMaker looses the record focus, if in the portal the record being deleted in the child table is the current record in the master table (portal row shows a selfjoin). So we scripted a check, whether the record number in found set is zero after the deletion and if that happens, we set it to the first record.

          • 2. Re: FM 12 - Severe bug in portal rows ?
            Malcolm

            FileMaker looses the record focus, if in the portal the record being deleted in the child table is the current record in the master table

             

            Hilarious. If you delete the current record via a portal the current record is deleted and filemaker loses it's "focus" because all the meta-data stored in the record is gone, gone, gone.

             

            You might want to store the record number and the portal row number and use them to restore the focus.

             

            malcolm

            • 3. Re: FM 12 - Severe bug in portal rows ?
              intex

              I thought FileMaker would just point the focus to the next possible record - I didn´t think it could loose any focus since in form view there is always one record shown, one active record (at least when the database is not empty or you search for something inexistant).

               

              I would tend to think, this is a bug or at least something not very ellegantly thought.

              • 4. Re: FM 12 - Severe bug in portal rows ?
                Malcolm

                Perhaps I haven't understood what you mean by "lose focus"?

                • 5. Re: FM 12 - Severe bug in portal rows ?
                  intex

                  current record in found set = 0

                  • 6. Re: FM 12 - Severe bug in portal rows ?
                    timwhisenant

                    When you think about it FM has always responded to a non-matching criteria with the 0 record in the 0 found set state. I error trap for it in every find, since I don't want my users to feel stuck when what they are looking for is not found. Trapping for it allows me (the developer) to decide how I wish to inform the user of the not-found state of their search and what and how many records I want to return to the found set for them to view so they will not feel lost. So I guess this would be more of an inelegant situation than a bug. Trap for it, force a screen refresh, or maybe even a Commit Records script will help with re-establishing the current record focus, but at any rate you get to decide what happens next when you trap for it.

                     

                    HTH,

                    Tim

                    • 7. Re: FM 12 - Severe bug in portal rows ?
                      Stephen Huston

                      If you had a found set of 2 records, and you deleted those 2, one at a time, you would be left with a found set of zero, even if there are millions of other records in the table for that layout.

                       

                      Deleting the local parent record via a self-join portal can leave you in the same spot, with zero found records, depending on your found set. It's expected behavior.

                       

                      Any time you have no parent record, you should expect to see no child records. Again, expected behavior.

                       

                      If you want it to do something else, you need to script the deletion and test -- immediately following the deletion -- for a current found set of zero, and then figure out what should happen instead -- possibly a dialog box with a warning and an option to show all records or go into Find mode to search for a new found set.