It comes down to one question: Do you need workflow to trigger on the second form when updating?
If so then you have to use push fields and up the "Maximum filters for an operation". If you dont then you could use direct sql.
A probably reason for this error is that, on your destination form, there's a lot of workflow firing "on modify".
In this scenario, I'd suggest you two options:
- Increase the number of filters the server can process:
Remedy Administrator->Server Information->Advanced->Maximum Filters for an Operation
- Identify all the workflow that fires "on modify" on your destination form:
In my opinion, this is more feasible.
I'd do the following:
- Turn on server side filter logging just when modifying something on your source form
- Save the changes on source form
- Turn off logging
- Analyze log file searching all the workflow that fires "on modify" on destination form
When done, create some workflow (sample):
a) Add a zTmpfield on your source and destination forms
b) When the modification happens on source form, mark zTmpfield to "Yes"
c) Modify the filter that pushes modifications from source to destination form, including zTmpfield = "Yes"
d) Review the log you analyzed to check that there's no filter "on modify" on destination form with Execution Order = 0
e) If there's some workflow, try to increase a little bit its Execution Order
f) Create a filter that fires "on modify" on destination form, with Execution Order = 0 and Run If something like zTmpfield = "Yes"
f.1) this filter
-> first action: Call Guide
-> call a guide that contains the minimum workflow necessary to do your updating (you may have identified the really important filters you need when analyzing the log)
f.2) this filter
-> second action: Goto 1000
We did something like this on ITSM6.x: a Customer was used to "mark as duplicate" thousands of Incidents.
What happened when solving the master incident? A server crash...
So we decided to improve this by increasing the number of filters (we didn't experienced any improvement) and designing the mentioned workflow (tests made using 3000 duplicates passed to solved in less than 40'').
Hope this helps,
I agree with both suggestions, although if you are going to push a large number of records direct SQL would be preferable for performance as it will occur in one transaction.
Increasing the Max Filters will still use a "nesting" to complete the transactions, thus causing server degredation.
Did you find useful the answers to your questions?
If the child tickets which are attached in the master ticket are not in resolved status and in that case if you want to change the status of master ticket resolved then you will face that problem.
So first change the status of child tickets resolved and then master ticket.
If you are planning on being at RUG this fall, I would suggest you look into the breakout session hosted by myself as it addresses this type of subject and some alternative ways to work around the scenario, especially if you need all of the workflow to fire on all of the records which would make the existing suggestions not feasable.