4 Replies Latest reply on May 3, 2011 1:36 PM by rebelbroker

    Parsing numbers into multiple find requests

    rebelbroker

      Title

      Parsing numbers into multiple find requests

      Post

      So I have a list of numbers that I have captured from a different table in the database. I put them all into a global and go over to a different table. I now want to find all the records that match any one of the numbers. So, my global field contains say:

      1,2,3,4,5,6


      I do a search in the field "ScreenID" and I want to find all the records where ScreenID equals 1, all the records where screenID equals 2... and so forth for all the numbers listed.


      I have found that I can create multiple find requests to get the result i want, but I am wondering what the best way is to script this out. 

      I get the numbers I will later need to search on by copying them from various records and putting them into the global, separated by commas. It would seem like there is a better way to do this than to capture them in some loop script step, then move over to do the find in the other table and do another loop there to parse out the numbers into different find requests.


      What am I missing?


      Thanks,

      R

        • 1. Re: Parsing numbers into multiple find requests
          philmodjunk

          One way to avoid the loop for capturing the values in the first place is to use copy all records.

          If you switch to a layout that only has the screenID field on it, CopyAllRecords will copy the ScreenID numbers of all the fields to the clipboard and then your script can change layouts yet again to a layout that has your global field and then it can paste the list into the global field. The values in this field will be separated by carriage returns rather than commas.

          If you define a relationship such as:

          YourTable::GlobalScreenIDList = YourTable2::ScreenID

          You can then use Go To Related Record to pull up all the values listed in the GlobalScreenIDList field, as long as the listed values are separated by returns instead of by commas.

          • 2. Re: Parsing numbers into multiple find requests
            rebelbroker

            Ok, so I now have my global field with all the "ScreenID" values separated by a carriage return.

            Now table1 already has the following relationship:

            Table1::ScreenID = Table2::ScreenID

            This allows me to see just a list of the items in table2 that pertain to that screen record.

            What I am going for is being able to see all the items that pertain to the current found set of screens.

            I created a relationship as follows to try and do what you describe:

            Table1::gCurrentFoundScreens = Table2::ScreenID

            However, I was not able to figure out how to view this using the gCurrentFoundScreens field. It is merging the two relationships into one it seems.

            I created a duplicate of table1 and then created a relationship from the global to ScreenID, but in that case, the portal used simply repeated the first record of table 2 over and over

            • 3. Re: Parsing numbers into multiple find requests
              philmodjunk

              gCurrentFoundScreens can be defined in any table in your database, but the Go To Related record script must be performed from a layout based on the same table as where you defined this field.

              If you have this relationship:

              Table1::gCurrentFoundScreens = Table2::ScreenID

              Then this script will pull up the records listed in the global field:

              Go To Layout [table1] //Any layout that refers to Table1 in Layout Setup...|Show Records from will do here
              Go To Related Record [Show only related records; From table: Table2; Using layout: "Table2" (Table2)]

              You can choose any layout inside the Go To Related Record step that refers to the same data source table asTable2.

              • 4. Re: Parsing numbers into multiple find requests
                rebelbroker

                Thanks for that.

                In creating duplicate tables I had screwed up various relationships that were keeping this from working. 

                With your help, it is more simple and useful.

                Thanks!

                R