Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

Possible fix to POST_EVENT (OpenInsight 64-bit)

At 29 OCT 2019 11:15:24AM Richard Hunt wrote:

Version OI 9.4

Seem to have resolved the "POST_EVENT stop working" issue.

What I did was to use the sentence "RESULT = SET_PROPERTY('SYSTEM','IDLEPROC','QMANAGER')". This seems to "restart" the handling of POST_EVENT processing again without restarting OI.

I have never used the IDLEPROC property. I am not sure what QMANAGER does, I am only guessing it handles or manages the queued events including POST_EVENT. Will executing the above sentence cause unforeseen issues?

Using the sentence "OPEN RECORD FROM FILE_DATA, ID THEN" with FILE_DATA being unassigned will cause the debugger to have what I would call a "fatal" error issue. It then seems to not handle any more POST_EVENT's without restarting OI.

Since approximately half of my stored procedures, 444 of 925, use POST_EVENT and the issue of POST_EVENT to stop working does cause me to pursue a resolve. Otherwise I would not attempt such a "tweak".

I use POST_EVENT to allow event "A" to finish before event "B" begins. And I use it to process SELECT / READNEXT loops so as to be able to do other things while a long SELECT / REAENEXT process is under way.


At 07 NOV 2019 07:04AM Carl Pates wrote:

Richard,

Calling QMANAGER yourself will not cause you any problems.

IIRC It simple processes the POST_EVENT queue by tacking it onto the IDLEPROC processor, which will run an event and then re-add itself to IDLEPROC if the queue isn't empty to run the next one. If you hit a debug condition inside the event call that resets the engine (i.e you hit a fatal error or you close the debugger) then the call to re-add will never get executed so I think that's why your POST_EVENTs stop working?

Carl Pates


At 14 NOV 2019 10:22AM Donald Bakke wrote:

POST_EVENT stops working when its global common variables fails to get cleared. You can fix this in code this way:

	COMMON /%QMANAGER%/ Queue@, bQueueActive@, RequestHold@

	

	Queue@          = ''

	bQueueActive@   = ''

	RequestHold@    = ''

Don Bakke

SRP Computer Solutions, Inc.


At 14 NOV 2019 02:13PM Richard Hunt wrote:

Worked. I am currently using your method. This is greatly appreciated.


At 14 NOV 2019 07:31PM Donald Bakke wrote:

Post removed by author


At 14 NOV 2019 07:33PM Donald Bakke wrote:

Post removed by author


At 14 NOV 2019 07:37PM Donald Bakke wrote:

COMMON /%QMANAGER%/ Queue@, bQueueActive@, RequstHold@



Queue@          = ''

bQueueActive@   = ''

RequestHold@    = ''

Don Bakke

SRP Computer Solutions, Inc.


At 14 NOV 2019 07:38PM Donald Bakke wrote:

Finally. Had to retype by hand. Unicode characters were embedded in the string.

Don Bakke

SRP Computer Solutions, Inc.


At 14 NOV 2019 07:53PM Barry Stevens wrote:

@DonBakke

Never seen this before, under what circumstances do you need to do this? - Is it only when you directly reference QMANAGER (never heard of that) or every time you do a post_event!!!!


At 14 NOV 2019 08:05PM Donald Bakke wrote:

This is only a corrective action you need to take if you suspect POST_EVENT is no longer working and you don't want to restart OI. POST_EVENTs start to fail when some runtime errors occur. It doesn't happen for all runtime errors so I don't know what the specific cases are.

Don Bakke

SRP Computer Solutions, Inc.


At 14 NOV 2019 08:11PM Barry Stevens wrote:

  • third_party_content/community/commentary/forums_works/c6d8dd45ae1f064180b54363aa104daa.txt
  • Last modified: 2024/01/04 20:57
  • by 127.0.0.1