I just ran into a performance issue with ApplyUpdates. I noticed applying updates on a specific table when I added 200 records, was taking 25 seconds! After some debugging, I found out the actual applying of updates took less than a second, but it took 24+ seconds to merge the deltas. I disabled all data-aware controls thinking it was that, but the problem persisted. After some more research, I found out MergeDelta was calling Edit…Post for each delta it needed to merge, which was causing my BeforePost and AfterPost events to be called, on top of the OnCalcFields being called all the time during the process. In this case, there was a lot being done in the AfterPost event which was causing the performance bottleneck. Once I removed these events before calling ApplyUpdates, the entire process took a bit over 1 second.
My question is: since MergeDeltas is an internal process, shouldn’t all events be internally disabled during this process (e.g. BeforeEdit, AfterEdit, BeforePost, AfterPost, OnCalcFields)? For me ApplyUpdates is one process, not 200 edit/post tasks, and should not be triggering outside events when merging the deltas back. When I added 200 records, I already called BeforePost and AfterPost 200 times, so why would I want these events to be called again, just to update the autoincs from the server? There is DisableEventsWhileStreaming option, which maybe should be considered here, as merging the deltas back is in a way, part of the applyupdates/streaming process.
I know I can disable these events before calling ApplyUpdates (this will probably now become standard code before calling ApplyUpdates) but I find it odd that an internal process of the data table is using Edit…Post, as if it were being called from outside the data table, and I was wondering if this is (may be) more of a bug than WAD.
Thanks,
Arturo.