3 Replies Latest reply on Jun 16, 2011 9:07 AM by philmodjunk

    help with a slow script using replace field contents

    slaglemark

      Title

      help with a slow script using replace field contents

      Post

      hello, thanks for your time.

      i am experiencing some major slowdown when running a particular script.

      i am using a portal from a self-join relationship to display a list of data below some summary data in IWP.

      to force the portal to show the found set from the first table instance, i have a field called PortalKey.  this field has a static value of 1.

      the script performs a find, then sets the related PortalKey field from the other instance of the table to a value of 1.

      thus, the portal shows me only the proper records. 

      i then simply delete the value in PortalKey for all of the records whenever a user resets the search.

      i am finding that this process is slooooow.  

      is there a better way?

      thanks!

        • 1. Re: help with a slow script using replace field contents
          philmodjunk

          Not only is this slow, but two users doing this at the same time will see each other's selected records.

          Why not put the summary data in the header and use a list view of the recrods found instead of using a portal?

          • 2. Re: help with a slow script using replace field contents
            slaglemark

            @Phil i chose the self-join portal because i really want a scrollable list of related records, rather that having users use the 25 records at a time method.

            i prefer to just close and lock the sidebar, rather than offer users more places to mess things up.

            i cant think of a way to solve this issue tho.  perhaps i need to rethink?  how else can i get related records to show up?

            • 3. Re: help with a slow script using replace field contents
              philmodjunk

              The problem here is that you don't have related records until you go through a lot of steps to establish the relationship. You can add your own button for the next 25 or so records to your layout so that you can still hide the status area. I think you should consider that option carefully as it is much simpler and faster than putting together a portal that lists your found records.

              As it happens, I do know of a method that may work--haven't tried in an IWP setup so you'll have to test. It should be a little bit faster, and the found set of one user won't get mixed together with the found sets of other users.

              Using your self join, set up this relationship:

              Main::gIDList = FoundSet::IDfield

              Main and FoundSet are table occurrences of the same data source table. gIDList is a global text field. IDField is a field with an auto-entered serial number so you can uniquely identify every record in your found set. If you haven't already defined such a field, you'll need to add it, then use Replace Field Contents with the serial number option to add a serial number to all existing records in this table.

              Add two layouts to your solution, both based on either Main or FoundSet. (Specify the same table occurrence your script uses when performing the find for the "IDFields" layout I describe next.)

              Put gIDList as the sole field on layout "ID GLobal". Put only the IDField on the  layout called "IDFields". Do not put any other fields on this layout.

              Now after performing a find to find the records, your script would do the following:

              Go to Layout["IDfields"]
              Copy All Records
              Go To Layout ["ID GLobal" (Main)]
              Paste [Main::gIDList]
              Go To Layout [original layout]
              Commit Record

              Copy all records copies the data of your found set to the clip board. Data from all fields on the layout are copied. The individual field values are separated by tab characters, records are seperated by returns, so with this layout, you get a list of all the serial numbers of your found records copied to the clipboard.

              In a FileMaker relationship, putting a return separted list of values into a key field matches any single value in the list to values in the related table so this will give you a portal of your found records. Since this is a global field, your different users can each produce their own lists in this global field without one user's found set showing up as part of the recors in another user's portal.