01-06-2010 08:28 AM
As a result of network interruption during script execution, some of the remote devices never received the ccCopyEntryRowStatus "destroy", so I assume that field remains set to createAnd*. Would there be any danger leaving that "as is", especially considering the next execution will again attempt to set it to createAnd*? On the flip side, what happens if ccCopyEntryRowStatus receives "destroy" when it's not set (or would that be the "notInService(2)" state)?
Solved! Go to Solution.
01-06-2010 09:25 AM
Yes, you can, and I do in all of my scripts.
No, that won't work. If a row is in a createAndWait state, it must be set to active, not createAndGo.
01-06-2010 09:09 AM
There is no danger. Assuming your next run of the script will do a destroy before trying to reset row objects, you will be fine. Of course, if you're worried about it, you can always send a destory after the fact, and clean things up now.
01-06-2010 09:22 AM
Is it to say I could summarily issue a blind "destroy" upfront regardless, as a "best practice"?
To restate my original question: Is there any [adverse] impact if ccCopyEntryRowStatus that's left in "createAndWait" state receives another "createAndWait" directive immediately after?
01-06-2010 09:25 AM
Yes, you can, and I do in all of my scripts.
No, that won't work. If a row is in a createAndWait state, it must be set to active, not createAndGo.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide