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"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
