Registered: 1237467001 Posts: 71
Reply with quote
We introduced a new Flag in a 188.8.131.52 process. This flag is designed to move Folders in a "Closed" stage back into an "Active" stage via a common action. From what we understand you can't do this to existing folders as they do not have the appropriate eWait entries and Raising the flag just won't work.
So the trick, that works in DEV and UAT Environments was to (within one code activity) 1. Insert row into eWait with the flag name, folderID, etc. 2. Call Mstm.RaiseFlag with the new flag name. We rolled out to productiton Friday morning and flags were not getting process, though there was nothing sticking in eRaisedFlag, no errors, etc. So I'm thinking that it's because of the transaction nature of 9.2. That is, everything in that code activity is committed at once. Production is way busier. And the eRaisedFlag is cleared before eWait is entry is registered. So the only workaround: 1. Action 1: Insert into eWait. 2. Go to System Stage. 3. Action 2: Call Mstm.RaisedFlag 4. Continue to destination (previously existing stage). Any thoughts about... any of this? Maybe it's all wrong to begin with. Paul
Registered: 1158198299 Posts: 5,507
Reply with quote
I suspect this is a speed issue. Dev is probably slower, so the eWait entry is inserted before the flag is raised. In Production it is not there yet.
You workaround works, but we also have an admin form in our System Management solution that inserts the required eWait entries for you in bulk. __________________ Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.