Sounds like a plan, glad it helped.
Just a thought. Are there many child records? If so, the prep/load time may
suffer if you copy all children recs. You could use the child form as the
source for the table, and only save modified children in temp form. Then
update when parent finishes. Drawback is that changes will not be visible to
the user until the children are updated.
Another consideration is record locking. What's the likelihood of 2 people
editing the same parent at the same time? You may need to build workflow to
prevent this. (i.e.: Check if active parent relationship exists in temp, if
so, don't allow edit, if not allow.)
I'd be curious to see others ideas on how to address the locking issue. Are
there better ways? Does Remedy provide a check? I'm sure this isn't unique
situation.
Thanks,
Mark
________________________________
From: Action Request System discussion list(ARSList) on behalf of Brien Dieterle
Sent: Fri 2/6/2009 11:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: transaction for parent/child changes
** Thanks for the suggestions!
So I might have 3 forms. Primary, Child, and Child-temp...
So for editing an existing request w/ existing children I might have an onload
activeLink Guide that pushes all the existing Child requests into the
Child-Temp form, and the Table List field on the primary form would actually be
attached to the child-temp form, not the actual child form.
Brilliant! Thanks for the suggestion both of you. I was thinking I would
duplicate fields on the child-form for holding present and previous values, but
this is much cleaner!
Still... wouldn't it be nice to be able to say "start trans" or something? :-)
Thanks again
Brien
On Fri, Feb 6, 2009 at 8:53 AM, Mark Lev <mark....@rightstarsystems.com> wrote:
Perhaps a staging form that holds the child modifications, and a
routine to push them to actual when primary form is confirmed.
Mark
________________________________
From: Action Request System discussion list(ARSList) on behalf of Brien
Dieterle
Sent: Fri 2/6/2009 10:34 AM
To: arslist@ARSLIST.ORG
Subject: transaction for parent/child changes
** We've designed a form that has child requests displayed in a table
list field. You can interact with these child requests through this form and
update them via display only fields and push-fields activelink buttons etc. So
the problem is you can update some things on the main form, and update some
children requests, close the main request and say "yes, lose changes". A user
might expect that the changes to the children would be reverted back to what
they were.
Is there any way to encapsulate the whole process of editing the
primary requests and N children requests into a single transaction that gets
committed only upon saving of the primary request?
Thanks!
Brien Dieterle
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
<http://www.arslist.org/>
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
