Has anyone tried adding an onRecordInsert, onRecordUpdate or onRecordDelete method on Servoy’s built-in AuditTrail log.dbi?
The methods works if I tried it on other tables but it doesn’t when I use it in log.dbi. I restarted my workstation but it didn’t fix the problem. Did anybody encounter the same problem as mine? Thanks.
Yep. I tried that too a while ago and it didn’t work for me either.
I suppose it’s normal since events in the log_server wouldn’t know which solution to callback since the logs can be coming from a number of concurrent solutions…
ptalbot:
Yep. I tried that too a while ago and it didn’t work for me either.
I suppose it’s normal since events in the log_server wouldn’t know which solution to callback since the logs can be coming from a number of concurrent solutions…
The logging doesn’t happen in the Client, as that would be way too much overhead.
Your table events would only be fired if you do CUD operations directly on the log table from within your client, which defies the purpose of the logtable.
pbakker:
The logging doesn’t happen in the Client, as that would be way too much overhead.
Your table events would only be fired if you do CUD operations directly on the log table from within your client, which defies the purpose of the logtable.
Paul
Hi Paul, does this mean that if I add codes in any event of any dbi file, these codes are executed on the server?
Logging is done on the Server, not in the client, so the logging mechanism doesn’t know about any code in table events, because those table events are run in the client.
Only when you would interact with the log table from within a client (for example have a a form build on top of the log table and allow users to insert/update/delete), then the table events would fire, but of course only for the actions done by the client.
Logging is done on the Server, not in the client, so the logging mechanism doesn’t know about any code in table events, because those table events are run in the client.
Only when you would interact with the log table from within a client (for example have a a form build on top of the log table and allow users to insert/update/delete), then the table events would fire, but of course only for the actions done by the client.