Thanks everyone! I think I'm going to go with allowing the customer to set to Delete and then having the escalation do it the actual delete at a later date.
Thanks! Lisa ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Thursday, November 10, 2011 2:26 PM To: arslist@ARSLIST.ORG Subject: Re: Deleting Records in the UAT ** Another method if you don't want to have an Escalation and you have DSO is to push a record to the Distributed Pending form and let it delete the record in the background. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Thursday, November 10, 2011 12:14 PM To: arslist@ARSLIST.ORG Subject: Re: Deleting Records in the UAT ** Lisa, The problem you are having is a characteristic of how the clients work. When you have a record open for modify, what the client does is the following: Save the record using the ARSetEntry() API call All your logic fires here Get the record again using the ARGetEntry() API call to refresh the screen with any changes that may have been done by workflow Well, you just deleted the record so the Get will fail.... There are two directions you can take: Direct delete and close the screen Deferred delete Direct delete would mean to change the method of delete. Rather than do a status change, you would use an active link with @@ to do the delete and close the window - basically, see Misi's note and follow that set of directions. This would do the delete, drop the record, close the window so there is no refresh or attempt to reuse the window. Deferred delete would be to do the same thing you are doing today but drop the filter that does the actual delete and have an Escalation do the work for all records with a status of Delete. There would be a delay between the marking and the actual delete. There are pros and cons with each approach. One does the work immediately but there is no "oops, I didn't really mean it" out. The deferred approach would let you delete and you have time to change your mind (maybe you have the escalation leave it for a week and then delete). You could adjust the consoles to not show things in "delete" state so they are not visible. You need to make the call about which approach is the right one for your situation. Note, you could leave the current approach in place to be able to be used by API clients or web services or other methods than the client. You could even have the action the user takes be the same but just have workflow that On Modify checks to see if set to Delete and then do the clear change flag, tell server to run process to delete, close window. But, if you do this, note that you are closing the window and if you had a series of entries from a result list, that list will close with the form you are closing. So, you will not be able to walk to the next record. There are other permutations of the two options, but they come down to one of the two basic approaches noted here. I hope this explanation of the behavior and actions of the client help you understand what is happening and lets you select the option that best fits your needs. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kemes, Lisa Sent: Thursday, November 10, 2011 8:28 AM To: arslist@ARSLIST.ORG Subject: Deleting Records in the UAT ** We are currently on ARS 7.1 p7, Oracle 11g and I have a filter that when a customer selects "DELETE" for the status and then saves the record, I do a Run Process and run this in the cmd line: Application-Delete-Entry "On Call Workstation" $Request ID$. The customer then gets this error message: [cid:116085613@11112011-2E02] Is there any other way around this so the customer doesn't get this error message? I know what it means, but it confuses the customers. I could just have them select DELETE and then run an escalation and delete it later on, but then the customers wonder why the record doesn't go away after they select Delete. Just wondering.... Lisa Kemes AR System Developer TEIS - USA +1 717 810 2408 tel +1 717 602 9460 mobile lisa.ke...@te.com<mailto:lisa.ke...@te.com> 100 Amp Drive Harrisburg, PA 17112 [http://www.te.com/images/socialmedia/smallTElogo.gif]<http://www.te.com/> www.te.com<http://www.te.com/> [http://www.te.com/images/socialmedia/twitter.png]<http://twitter.com/teconnectivity>[http://www.te.com/images/socialmedia/facebook.png]<http://www.facebook.com/teconnectivity>[http://www.te.com/images/socialmedia/flickr.png]<http://www.flickr.com/photos/teconnectivity/>[http://www.te.com/images/socialmedia/linkedin.png]<http://www.linkedin.com/groups?gid=1591657>[http://www.te.com/images/socialmedia/youtube.png]<http://www.youtube.com/teconnectivity> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
<<inline: image001.jpg>>
