6 Replies Latest reply on Apr 20, 2011 6:41 PM by Frinholp

    Scripting no No Records Found

    Frinholp

      Title

      Scripting no No Records Found

      Post

      Hi all

      In my search facility you can search, search within the subset and then perform a find within these results.

      I have used Get ( FoundCount ) to determine whether any records have been found. If no records have been found, I intend to display a dialog to state as such and revert back to the last found set.

      I do not want a situation where there is a zero found set in my system. 

      This presents a problem where if I perform a find and then delete all the found records, I will be left with a found set of zero records. If this situation arises, I wish to display I dialog stating that there are no records present in the found set, then revert back to the previous find (if the last find was a search within a subset) or show all records if the last find was a find performed on all records.  

      Any ideas?

      Thanks in advance

      Lee

        • 1. Re: Scripting no No Records Found
          philmodjunk

          You have several options depending on what you need and how many records are involved:

          Option 1: Save the criteria for the previous find and repeat the find with those criteria when there are no records found.

          Option 2: Save a list of the Primary keys of the current found set in a global text field. You can use Copy All Records from a layout that only shows the primary key field to quickly copy a list that you can then paste into the global text field located on yet another layout. If you have a self join relationship between this global field and your pimary key field, go to related records can "restore" your found set.

          Option 3: Create an extra table occurrence of your layout's table. Create a new layout for this table occurrence. Perform your find on this layout. When no records are found, revert to the previous layout where the found set will remain unchanged.

          Option 4: Do the same trick as Option 3, but instead of a new table occurrence and layout, open a new window for the find.

          • 2. Re: Scripting no No Records Found
            Frinholp

            Cheers Phil

            I have analysed the various options.

            My conclusions:

            Option 1: Seems to be a viable option but I'm unsure how to save the search criteria to repeat the find. Less layouts, less TOC and no freezing window (which causes 'flicker' in Windows). Performance I expect to be slower than the other options.

            Option 2: I expect this to perform faster than Option 1 but will require a freeze window.

            Option 3: I was unaware that an unrelated TOC of a table would 'hold' its found set if a find is performed on a different TOC of the same table. No freeze window required. 

            Option 4: I would rather keep the user in the main window if possible.

            Could you please advise if my assumptions are correct?

            I have ruled out Option 4.

            In some tables, I could potentially have a lot of records, but the found set is probably quite small - Archive.

            Looking on how I could improve the system, using Option 1, maybe a global field could hold a list of of search criteria from subset to subset so that I could revert back to a found set other than the previous (which seems to be a limitation in Option 3 and 4); though I'm unsure if my understanding is correct?

            I would greatly appreciate it Phil if you explain the performance issues (or non-issues) on Options 1-3 as I intend to develop this functionality throughout my system, which has many tables, and would prefer not to have to change to a different option further down the road if performance is bad as records increase.

            Thanks,

            Lee 

            • 3. Re: Scripting no No Records Found
              philmodjunk

              When I use Freeze Window, I don't see a "flicker" in these types of scripts. (That's the main reason for using Freeze Window in the first place.)

              Option 1: is easiest to implement if the original find was performed from a script where the citeria were entered into globals before initiating the script. Then you already have your criteria in global fields and a script that uses it to perform your find.

              It's main limitation is that any ad hoc finds performed by the user entering find mode and entering criteria will not be preserved. And any records manually omitted from the found set will return with the find as well. Option 2 does not have these limitations, but is best used with smaller data sets. Large data sets can results in noticeable delays here--but then so can re-performing a find as in option 1.

               

              The way you "roll back" with options 3 and 4 is that you perform the same preliminary find both layouts/windows. When you want to roll back, you close the window or change back to the other layout. The main draw back is you need two of these for every stage of your progressive finds and with the duplicate layouts, you need to maintain two layouts so that they look identical. This can be very time consuming to maintain if your layouts have a lot of different objects on them--especially portals.

              Here's an option 5 I just thought up:

              Define a self join relationship:

              TOC::PrimaryKey = TOC2::PrimaryKey

              To preserve the found set, freeze the window and use Go To Related Records with the Match Found Set option and specify a layout and table to TOC2. Then return to your original layout. To restore the found set, reverse the steps, go to the TOC2 layout, use GTRR with the match found set option pointed back at your original layout and TOC...

              Haven't tested that idea but it should work--especially with relatively small found sets of records and would require much less design work and scripting to implement as the TOC2 layout can be just a blank layout.

              • 4. Re: Scripting no No Records Found
                Frinholp

                Thanks again for your response.

                Option 1 and 5 look good; I am going to sleep on it before making my final decision and will post which method I have opted for tomorrow.

                When I use Freeze Window, I don't see a "flicker" in these types of scripts. (That's the main reason for using Freeze Window in the first place.)

                Do you develop in Windows or Mac?

                If I create a simple script:

                Freeze Window

                Refresh Window []

                This causes the screen to re-draw in Windows causing a noticable 'flicker'.

                Should I be using a different method to 'un-freeze' the screen?

                BTW the machine I am using is medium spec in today's standards.

                Lee

                • 5. Re: Scripting no No Records Found
                  LaRetta_1

                  I haven't followed this entire thread but I can address your Freeze Window[] question.  You do not need Refresh Window[].  A Freeze Window[] automatically refreshes the window when the script ends.  It is the Refresh Window[] while causes the flash.

                  • 6. Re: Scripting no No Records Found
                    Frinholp

                    Thanks LaRetta

                    I assumed that to 'un-freeze' the frozen window would require a refresh otherwise it would be frozen indefinately.

                    As the saying goes, to ASSUME makes an ASS of U and ME Embarassed

                    I should have read further into this issue!

                    Again many thanks............

                    I now have a lot of Refresh Window [] to remove from my scripts.

                    Lee