|
| [WD20] - Trapping Security Mechanism Issue |
| Iniciado por guest, 14,ene. 2016 14:16 - 7 respuestas |
| |
| | | |
|
| |
| Publicado el 14,enero 2016 - 14:16 |
Hi All
I have an application which is updating various files throughout the day. It uses a thread for firing off update procedures. Occasionally I get a "security mechanism" triggered warning (see attached image). However, this dialog does not tell me what program and/or program line triggered the problem. Clicking the button offers no information that helps either.
I can click OK or Cancel and the program continues just fine but obviously I want to trap and handle this without intervention.
How can I find out the line triggering this issue?
[attachment 1850 wd20_error.png] |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:25 |
Hi JP,
This is probably fired from your thread where you modify the Window_Master file. This tipical case is on the HSave() line then a "change colision" is detected. Someone made a change while you were making in too.
If you want to ignore this message, you can:
- trap the messages and ignore them using HOnError(...hErrModify...).
- lock the file (or record) while you are working on it to make sure no one else changes it.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:33 |
| Alex, thanks. When I run an update to this file the thread is paused/stopped so I dont think the thread is the issue. The problem is where to put the ignore/trap ? There is no info regarding what program or line is triggering the error. Is there some trick or feature or trace which can be used to find out? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:44 |
Hi JP,
You are best placed to know where it comes from  . It obviously is at a given line where there is a HSave() on the Window_Master file. And since you work in thread, it's not even impossible that the change is done at the same time in another place in your application (and not from another user somewhere).
There are no easy tricks for that kind of case that I know of. Usually this is because there is a long delay before the reading of the data and the saving of the changes. Another process/user makes changes in the meanwhile. A solution is to reduce this delay as much as possible.
For the HOnError(), it can be placed in the main thread before calling your second thread. Any place. But you must find a way to reactivate it after your update if you want the use to know about this kind of problem usually.
I hope this can help you a little bit.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:48 |
| OK Alex. I have isolated just 2 locations of HModify() on this file in this particular sequence. There are no HSave() instructions. Neither of those HModify() lines are causing it. Weird. Will investigate further. Thanks. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:03 |
| Alex - OK, I think I found it. Using HOnError() has allowed me to trap the error and a custom error handler using dbgInfo() has helped me trace the specific program and line. Thanks. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:03 |
Hi JP,
Indeed, HModify() is the one to look for.
Forget not that a colision like that can be hard to replicate without manually by making, for example, code that does so (using an independant HFSQL context).
Context 1: read data
Context 2: read data / HModify()
Context 1: HModify() // Then you have the error.
The "Context 2" can be from another application too... or yourself manually changing the record in the data base.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:11 |
That was a good idea!
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | | | |
| | |
|