>>In the computer event logs:
>>2:24 pm
>>The description for Event ID ( 1000 ) in Source ( Application Error ) could not be found. It contains the following insertion string(s): SYSMANAGER.EXE, 4.5.3.0, 47139f24, CTSCHE~1.OCX, 6.0.0.0, 3caddfa6, c0000005, 00011ee9, 1f88, 01d2679c07498be2, C:\Program Files (x86)\OurPath\OurApp.exe, C:\PROGRA~2\COMMON~1\SIRIUS~1\CTSCHE~1.OCX, bdfba45d-d395-11e6-a92f-484d7ed12fa7, , .
>>
>>2:27 pm
>>The description for Event ID ( 1000 ) in Source ( Application Error ) could not be found. It contains the following insertion string(s): microsoftedgecp.exe, 11.0.10586.20, 56540c35, chakra.dll, 11.0.10586.545, 57a1b627, c0000005, 00000000000ebba6, 1b24, 01d267a120f2af3c, C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\microsoftedgecp.exe,
>>C:\Windows\SYSTEM32\chakra.dll, cfd08236-285f-4449-9366-2cb95f1a3475, Microsoft.MicrosoftEdge_25.10586.0.0_neutral__8wekyb3d8bbwe, MicrosoftEdge.
>>
>>-------
>>I think the second event most likely is unrelated.
>>
>>------------------------
>>I have various logs and I can see that there is also SQL Server connection issue prior to that error.
>
>I'd have something report a serious warning if the connection couldn't be reestablished automatically within a given time (few seconds, perhaps) and then, well, tell the users they can expect more errors until this is resolved. Though I don't expect a scheduler ocx to be a bound control and cause immediate tableupdate() anywhere, but then who knows the code better than you - you're working on it. So it's possible that pasting causes some tableupdate somewhere and that this is the cause, accidentally connected to OCX just to get you on the wrong track.
>
>>BTW, in the code I see many return statements inside the with thisform block. Can this contribute to the problem?
>
>Shouldn't be... AFAIK, being in a with...endwith block is just a shortcut to change the addressing mode for statements inside the block, basically I guess by creating a temp reference and switching all terms beginning with a dot to use that reference (and it seems to be a private variable, because this also works in anything you call - a procedure can have a bunch of .pem stuff and it would still work). So upon a return that temp variable would just go out of scope. Don't see how that would be damaging now and not at other times.

So getting rid of return in the with/endwith construction didn't help with the error :( I am wondering what else can I do - we're unable to reproduce the issue locally.

I'm trying to add ability to re-connect in our MySQLExec function in case of the error. In the log I see the following entries

12/26/2016 12:35:13 PM 45313.36 IBIRRE CLSS92 E Mysqlexec... Error: A SQL Server ODBC connection error occurred...

Program: BOOK_SCHEDULE.MY_PAGEFRAME1.PAGE1.SCHEDULE.CTSCHEDULE.BARADDED

ODBC Error Message: RVC__4T50FX5NP_conn

ODBC SQL State: null
ODBC Data Source Error: null
ODBC Connection Handle: null

SQL Statement:
select instr_type from dbo.b_instr where instr_id = 'GARY P' BOOK_SCHEDULE.MY_PAGEFRAME1.PAGE1.SCHEDULE.CTSCHEDULE.BARADDED()
12/28/2016 11:40:52 AM 42052.99 IBIRRE CLSS92 E Mysqlexec... Error: A SQL Server ODBC connection error occurred...

Program: BOOK_SCHEDULE.MY_PAGEFRAME1.PAGE1.SCHEDULE.CTSCHEDULE.BARADDED

ODBC Error Message: RVC__4T70N8LOO_conn

ODBC SQL State: null
ODBC Data Source Error: null
ODBC Connection Handle: null

SQL Statement:
select instr_type from dbo.b_instr where instr_id = 'GARY P' BOOK_SCHEDULE.MY_PAGEFRAME1.PAGE1.SCHEDULE.CTSCHEDULE.BARADDED() WEBPAGES

The query itself is very simple, of course, but the error message seems to refer to our database used for remote views (this is done to get the picture properly).

So, it looks like the connection with the remote views database is getting lost and then it's downhill from there.