I have a proc I'd like to run, optionally, on multiple engines.
I have the CreateEngine, CreateQueue, CreateRequest code all working with small test routines, but not when I call the particular proc I want to run.
I am 99.99% certain it's because it contains get and set_property commands, even though they're within if…then statements so they aren't used when the proc is run without a UI.
I suspect OI is hanging where it normally puts up the 'stored procedure can be executed in event-context only' message.
Is there an elegant / simple way around this problem?
I'd prefer not to strip out the get/set_property code as it's updating status messages and checking for cancellation.
I'd prefer not to have two versions of the same code.
I can't split the code into a UI-compliant shell and a subroutine because it would hit the performance too much.
What I *can* do is create a little subroutine to do the get and set properties, but as I said, calling a subroutine does have a performance impact so I'd rather not do it that way unless it's my only option.
Any ideas…? All thoughts gratefully welcomed :)
Use common variables
errr… yeah I know how to generically make a subroutine faster, but there still appears to be an overhead in calling one at all, which is what I wanted to avoid.
However, it's moot now, as OI has this morning decided *not* to let me sneak the get and set properties under the radar in their own little procs. It now seems to be going all the way down the chain of subroutines until it finds a set_property, and then throwing the 'event-context' message at me (if I run the proc from Sys Ed, or hanging the process in an engine.
I have too deep a chain of procs that must be able to run either via a UI, or inside an engine, to be able to create two versions of the code.
I *must* find a way of switching off this check or disabling the UI code so that it'll run 'silently'. Please tell me there's a way! :]
We haven't tested this but in theory you could write your own "IsEventContext" function and simply return true.
Of course it'd then be down to you to ENSURE you were in event context before you tried any Presentation Server specific stuff or you'd really do yourself over.
World leaders in all things RevSoft
Thanks, that's an interesting take.
Luckily, it appears there's a simpler explanation - I've been a muppet ;) The set_property thing seems to be an enormous red-herring - it doesn't stop a process running on an engine. I'd actually missed a call to a progress bar, and it was a failed 'start_window' that was causing the hang!
Which means, I think, that I'm 'sorted'.
Many thanks for your input!