tag:blogger.com,1999:blog-28669706.post559676272485431450..comments2024-03-25T08:33:57.056+01:00Comments on Gustaf's Microsoft Dynamics CRM Blog: How to stop infinite recursions/loops in PostUpdate CalloutsGustaf Westerlundhttp://www.blogger.com/profile/02522937600083440624noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-28669706.post-29270545992972678062008-05-06T09:00:00.000+02:002008-05-06T09:00:00.000+02:00I don't think this course of action is what "Anony...I don't think this course of action is what "Anonymous" was refering to, I believe it rather concerned looking in the pre and postXml and act only when certain specific fields have been updated.<BR/><BR/>The method you describe will work and has many advantages, for instance the option to choose if the callout functionality is to be run or not (by setting the variable). However it isn't as clean as "anonymous" has described, as it need an attribute to work properly.<BR/><BR/>GustafGustaf Westerlundhttps://www.blogger.com/profile/02522937600083440624noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-4882159029604114012008-05-03T01:10:00.000+02:002008-05-03T01:10:00.000+02:00Hi, just came across this post and though I might ...Hi, just came across this post and though I might add something to the subject. <BR/><BR/>My colleges an I, have been using a field per form in order to control this loop issue, I think it is in the line of what anonymous is saying. <BR/><BR/>We have a field (e.g.: ext_postUpdate) that is set to true on the form on save (from where we usually want the postupdate to be sensitive to), and in some some occasions (e.g.: updates caused by a Integration development) we set it to true also, when the request is postupdate for the first time we set the field to false (since we where going to update the record anyway, why note sending and additional field with the bundle), the postupdate event is, as expected, thrown a second time but, this time the field is set to false so no actions take place and the loop is avoided.Anonymoushttps://www.blogger.com/profile/15655740365870178025noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-87110410129627591992007-09-01T15:40:00.000+02:002007-09-01T15:40:00.000+02:00Hi again,You are right, of course. I hadn't though...Hi again,<BR/>You are right, of course. I hadn't thought of it and it is the best course of action but requires a lot more work. This can be used in all cases when working with postUpdates.<BR/><BR/>GustafGustaf Westerlundhttps://www.blogger.com/profile/02522937600083440624noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-81833656398538112362007-09-01T13:07:00.000+02:002007-09-01T13:07:00.000+02:00You could read out the pre and postimagexml and th...You could read out the pre and postimagexml and than verify/compare attributes you're trying to update in the callout.<BR/>Ok, it's a bit of extra work, but the memoryconsumption is normal, because after each run, all the objects are being destroyed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-28669706.post-19212631517520292172007-09-01T10:10:00.000+02:002007-09-01T10:10:00.000+02:00Hi,I am aware of the fact that the stringcollectio...Hi,<BR/>I am aware of the fact that the stringcollection isn't as memory effective as for instance using a string[] but it is enough for this task and simpler to use.<BR/><BR/>If you would have the kindness and share with us how that code would look, I would surely publish it.<BR/><BR/>If you would also tell us who you are, that would certainly give you the credit you deserve.Gustaf Westerlundhttps://www.blogger.com/profile/02522937600083440624noreply@blogger.comtag:blogger.com,1999:blog-28669706.post-51192140735228797872007-08-31T20:42:00.000+02:002007-08-31T20:42:00.000+02:00If you write better code, than you don't need this...If you write better code, than you don't need this memory consuming function.Anonymousnoreply@blogger.com