11 Replies Latest reply on Sep 7, 2012 12:37 PM by philmodjunk

    portal field loop

    synergy46

      Title

      portal field loop

      Post

      Hi,

      I have a portal with a field (Dues::Date) that when clicked, runs a series of scripts that punch values into various fields.  It works. 

      Because I have changed a lot of the script calculations in those scripts, after records from previous versions are imported, some fields are incorrect and need to have the Dues::Date - On Save script run.

      I need to loop through each record's (Members) dues Portal and run the associated script.  The number of rows in the portal varies from each record.

      I tried go to Dues::Date; Set Field[Dues::Date; Dues::Date] but that doesn't seem to cause the trigger to execute.  So, I thought I would 'loop' through the portal and run the associated script on each found row. 

      But, I can only find get(ActivePortalRow) as a portal row function.  

      I don't know how to send the 'pointer' to the next portal row?  And, I suppose if I can get to the 'next' row, I can test for Dues::Date="" to tell me that I am on the last row.

      How would you do this? 

       

      duesportal.jpg

        • 1. Re: portal field loop
          philmodjunk

          You've seen and so far not responded to the suggestion that fields such as membership year be a calculation field rather than a data field updated via script in another thread. That still remains the most trouble free way to resolve this issue and simplifies your database design as well.

          I've also recommended that if you need to update a field in many records at the same time, that you use the replace field contents tool.

          You can go to a layout based on the portal's table rather than this layout, put the cursor in the field to be updated. Select Show All records and then you can use a single Replace Field Contents operation to update the field for every record in the table. And you can use a calcualtion option to enter the correct data in the field given the values of other fields in each record.

          Set Field, BTW, does not trip any script triggers as it does not interact with your layout. It can, in fact, modifiy data in a field that is not even present on the current layout.

          • 2. Re: portal field loop
            synergy46

            Phil,

            Thanks for the reply. 

            As for the calculated field, I too wish I could do that, but the Year, for example, varies with each membership year range AND sometimes is set by the user to a value outside the membership range.  (Think prepaying dues for furture years).  So, that field remains script driven. 

            This sounds really efficient:  You can go to a layout based on the portal's table rather than this layout, put the cursor in the field to be updated. Select Show All records and then you can use a single Replace Field Contents operation to update the field for every record in the table. And you can use a calcualtion option to enter the correct data in the field given the values of other fields in each record.

            I never thought of doing it this way (my programming background is Cobol and Fortran ... ugh) so I gravitate to Loops... This is MUCH more efficient.  I will give it a try this P.M...... Thanks in advance.

            • 3. Re: portal field loop
              philmodjunk

              As for the calculated field, I too wish I could do that, but the Year, for example, varies with each membership year range AND sometimes is set by the user to a value outside the membership range.  (Think prepaying dues for furture years).  So, that field remains script driven.

              This can still be done as a calculation field or as an auto-entered calculation. If you used a calculation field, you'd add a separate field for prepaid dues in order to be able to enter data and still have a calculation field compute the year. A range of dates is not a problem here. (With an auto-entered calculation, you can have a field that calculates a value but which still permits editing the result.) An auto-entered calculation, does require special handling during imports however.

              • 4. Re: portal field loop
                synergy46

                Phil,

                Thanks again for the additional info and thoughts.  I *really* would like to simplify my app and I will have to ruminate on what you say about calculated fields.  At this juncture since I have about 150 lines of code in one main script and 4 subscripts that resolve all the error checking, range checking etc... I don't see how a simple auto-enter script can work.   But, if I don't think about what you say, I won't learn anything... So, onward.

                As for the Replace idea, I think I did what you suggested: created a layout based on Dues.   Put Dues;:Date on it.  Wrote a little script... (see below) and... NOTHING?

                I can tell that nothing is happening because when the date is clicked in, a date is selected (even the date already in the box) it generates the script cascade that puts a calculated value in Amt. Due.   When I run the script that does not happen. 

                There are not too many ways to screw this up; but I think I succeeded!  What am I doing wrong?

                 

                Ron

                • 5. Re: portal field loop
                  synergy46

                  BTW, I should restate that the goal is to run the script that normally runs when I click into the date field and select a date.  I need a script to do this because after importing records from a previous version, some newly created fields are NOT updated.   (I suspect this is where the calculated field would be handy) 

                   

                  I just want a script to do it so I and the user don't have to manually click through the entire database manually updating each Dues record for each member...  I do *not* need to change the date, just run the script on each Dues row date.

                  • 6. Re: portal field loop
                    philmodjunk

                    Your replace field contents step specifies a target field, but you have done nothing to specify what data shall be entered into this field. This is where you would specify a calculated expression that updates the value in that field. I can't tell you what that expression should be as you haven't specified how your original script determined what data to enter into this field.

                    I have about 150 lines of code in one main script and 4 subscripts that resolve all the error checking, range checking etc... I don't see how a simple auto-enter script can work.

                    Error and range checking would be done by validation rules, not the auto-enter calculation--whose sole job is to enter the correct data into the field. And often one adds a script performed onObjectSave or OnObjectValidate that errorchecks in a more immediate and user friendly fashion than the validation rules, which then serve as an "insurance policy" that errors will be trapped should the field be modified in a way that does not trip the script trigger.

                    • 7. Re: portal field loop
                      synergy46

                      Your replace field contents step specifies a target field, but you have done nothing to specify what data shall be entered into this field.

                       

                      I thought I specified that the Dues::Date field should be replaced with Dues::Date  (Itself)-- as in Replace Field Contens [Dues::Date; Dues::Date].   Or, is this not a valid 'field calculation'? 

                      I think I am missing something here...

                      • 8. Re: portal field loop
                        synergy46

                        I just went to a script that is triggered by the Paid field.  I copied that script to the clip board.  Then I went to the Replace function and tried to paste it into the 'calculation' area.  I can't do that.  The Edit/Paste command is grayed out and cmd-V does not work either.

                        It seems to me that replace is made to replace all designated fields with a single, calculated value.  Do I have that right? 

                        If so, since I am trying to run a script on each field in each row of a portal I don't see how using Replace can work?  Sorry to be so dense but I just don't get it.

                        • 9. Re: portal field loop
                          philmodjunk

                          Sorry for not looking more closely at that script step.

                          Replace Field Contens [Dues::Date; Dues::Date]

                          will not change the value of your field and thus does not do what you need here. We are coming at this with different assumptions. You want to use a script to trip an existing script trigger, I am suggesing an approach that uses a calculation to compute and enter the necessary data into this field.

                          It seems to me that replace is made to replace all designated fields with a single, calculated value.  Do I have that right?

                          The calculation you specify will evaluate once for each record as replace loops through your found set and updates the target field. Thus, a different value may be entered into each and every record with a single replace fields operation if you create a calculation that successfully computes the needed value for each and every record.

                          • 10. Re: portal field loop
                            synergy46

                            Phil, did you get the link to my video?  It shows 'why' I can't use a simple calculation field --- sigh-- (As much as I would like to)

                             

                            Ron

                            • 11. Re: portal field loop
                              philmodjunk

                              Yes, but your PM did not contain a link back to this thread so I did not have any "context" as to which thread was yours. I also do not have speakers for the machine that I am currently using so I won't be able to watch that movie and hear anything until much later this evening when I can use my personal machine at home.

                              I can tell you that even very complex data entry can be managed with an auto-enter calculation with the correct  use of Let, case and possibly a look up table of values--especially if you use OnObjectValidate and Validation Rules to trap for data entry errors.