>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.