The # 20 accounts for the number of questions in the current Base form (Form -A). And the 20 Push field action in turn creates 20 records in the Form B.
Thanks,| Shiju... On Mon, Aug 29, 2011 at 7:41 PM, Chintan Shah <cbss...@yahoo.com> wrote: > ** > Just out of curiosity, why would you have 20 push fields actions..what > drives that #? > > Thnx > Chintan. > > ------------------------------ > *From:* Shiju John <johns...@gmail.com> > *To:* arslist@ARSLIST.ORG > *Sent:* Sunday, August 28, 2011 11:32 PM > *Subject:* Re: Any Method to check within a record for 'not null' options? > > ** > Hi, > Thank you guys for your valuable inputs. > I have implemented the same with another approach. I am doing my testing on > this, and as of now the performance looks fine. > Just thought of sharing the same :). > > Created a New Form (Form B)- to hold the Candidate keys and a question > field (character) and an Answer Field. > Work flow: > 1. On submit on Form A (current Base form), push each "Question $ Answer" > to Form B, where > 'Question' = $Question1$ > 'Answer = $Answer1$ > > similarly 20 push field actions, irrespective of the Question/Answer > being Null or Not. > > 2. On submit on Form B, another filter which checks if Answer or Question > is Null. If yes, just delete that record. > > Advantages of this approach, > 1. No modification required in the workflows for the addition/deletion of > questions. > 2. Form B holds all the answered questions. > 3. No table looping, and hence better performance. > > Please let me know your comments on this approach. > > Thanks, > Shiju... > > On Sun, Aug 28, 2011 at 8:20 PM, Chintan Shah <cbss...@yahoo.com> wrote: > > Hi John, > > I had a similar scenario to work with in past. Let me share the solution > with you and list. I am assuming that users will answer data in character > field. > > There should be 3 forms in total > a) UI form. > b) Questions form > c) Transactional Form(copy of questions form+a character field to answer > the question+1 field to hold GUID passed from UI form) > > Here's flow: > > 1. On UI form, have a table field that represents the transactional form > and a display-only character field(for answers) and "Save" button next to > that table. Have another hidden table field that represents "Questions" > form(there should not be any qual on this unless you wanna load specific > questions). > > 2. On load of UI or on focus of "Question/Answer" tab(whichever you > prefer), perform the following: > > a) Change field -->Refresh "Questions" form. > b) Call guide to walk thru questions form. As you are walking through > each record(which in this case is "question"), push each record to > transactional form along with GUID.You can generate a GUID on UI table and > use that and push it to transactional form as well so that you qual on > "transaction" table in UI would look like 'guid'=$guid$. > c) Change field-->Refresh "transactional" form and "Set focus". > > System is now ready for users to enter the answers. > > 3. On selection of record on "transactional" form, load "answer" field > from transactional form into the display-only character field(initially it > will be NULL). Train users so that they can enter answers in this field and > have workflow on "Save" button so that it pushes the answer back to > transactional form. Next time the users loads up the record they will see > the answer. They can edit the answer and use the same "Save" button to > commit it. > > Advantages of this approach: > 1. You do not need to add/modify any workflow whenever new questions are > added. As a matter of fact, questions can be added at any time since it will > be just data. > 2. Re-usable "Save" button/generic workflow for saving all records. > 3. Generic workflow to load the table, pushing records to transactional > form. > 4. You can re-use the same workflow on multiple forms if there is a need. > > In a nutshell, "Write once-use anywhere" kind of workflow and much less > overhead to maintain. > > Disadvantages: > 1. User will have to answer each question separately and hit "Save" button. > > Total # of active links: 4 > 1. To perform "call guide" action on "questions" table and actions for > refreshing of questions/transactional table. > 2. To perform "push fields" to the transactional table. > 3. To load data from transactional form when a record is selected. > 4. "save" button workflow to push the answers back to transactional > form. > > Active Link Guides: 1 > 1. Walk thru "Questions" table once(should be on $OPERATION$=CREATE). > > There could be 100 questions and you can still use this approach. You do > not need to create 100 Active Links. > > I have not seen any performance issues with this approach so far and users > are quite happy with it. > > HTH. > > Thanks > Chintan. > ------------------------------ > *From:* Shiju John <johns...@gmail.com> > *To:* arslist@ARSLIST.ORG > *Sent:* Sunday, August 28, 2011 1:12 AM > *Subject:* Any Method to check within a record for 'not null' options? > > Hi, > I have a generic issue. The issue is as described below: > I have a form which stores 20 questions. These questions are not mandatory, > and the user might answer any "n" questions out of this 20. I need to do a > customization such that i need only the questions answered to be pushed to a > new form, which segregates each of these "n" questions to "n" records in the > new form. > The basic and easiest approach would be to create 20 activelinks which > checks if each question is answered or not, and based on that do a push to > the new form. But this would degrade the performance as there are chances > that the number of questions might increase in future. And this approach > would be a hard code( method of implementing 20 active links) , and not > configurable. Could some one suggest me a better approach to do this? > > Please pour in your thoughts !!! :) > > Thanks, > Shiju. > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > > > > > -- > > Thanks and Regards, > Shiju John > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ > -- Thanks and Regards, Shiju John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
