Hi all. I am experiencing what in my oppinion is a bug in Navision. This is the case: I have made a dataport to export from i.e. the Vendor table. The dataport works correctly when run from Object Designer. Now I want the dataport to run every time a vendor is changed. But by using MyDataport.RUN in the OnModify() trigger, I seem to force the system in some kind of a loop. It runs the OnModify (and the dataport) over and over until it crashes. [:(!] Here comes the really weird thing… when I run through exactly the same transaction (modifying a vendor) with the debugger active (breakpoint on triggers), it works!!! [}:)] The debugger seems to have some affect on how one transaction behaves when another exits. A possible solution is to use runmodal(true) to use request form, but that is definitely not desireable. That would require a COMMIT in the OnModify trigger, and would slow down the process. I have tried various possibilities; using OnMofifyRecord in the form, instead of OnModify in the table; using DATAPORT.RUN(DATAPORT::“My dataport”), instead of MyDataport.RUN; calling a codeunit from the OnModify trigger and call the dataport from there. Nothing works. [V] It seems as if I will have to “rewrite” the dataport into a codeunit and use File.WRITE. If anyone knows another solution I would be very grateful. Also I would like to see a response from Navision, if this is a known issue. Sincerely, Stefan Jonsson, Developer, Maritech NSC, Iceland
I suggest you to read the Application Designer’s Guide, Chapter 24.3, “The Command Buffer”. The command buffer bundles requests to the database to send them as a package instead of sending them one by one. When you use the debugger, the command buffer is deactivated, which is sometimes causing problems you don’t have when not using the debugger or vice versa. To test your dataport without the debugger use the return values of functions and procedures (e. g. ok = record.get) to bypass the command buffer and see if it works.
Stefan, which version are you using? I faced a similar problem in 3.6 (all versions), but only 3.6 calling a report from the OnModify trigger. A simple “message” BEFORE calling the report and it worked (like Alex suggested “OK = record.get” was the solution then). Regards Walter
Thank you, Alex and Walter. I’ve been trying this in Attain 3.01 and 3.6. I tried various versions of MESSAGE and CONFIRM before and after each function call. It made no difference and neither did switching VAR on/off in parameters. I just noticed now that it is only in 3.01 where the debugger makes it work. Maybe the new debugger in 3.6 does not turn off the command buffer? I do not quite understand how I can use return value to help me. I can not use Ok := Dataport.RUN. I tried to call a function with return value in a codeunit from the OnModify trigger… [xx(] P.s. I have not faced any problems using this procedure in OnDelete()
I ment to use the return values in your dataport wherever possible, because this is the part causing trouble when you don’t use the debugger (and no command buffer). But this wouldn’t be a proper solution, it should only help you finding the problem. Are you trying to export the record that was modified? Because this may cause some trouble since the record the dataport is trying to read is not modified at this time. It will be after the OnModify-trigger has run completely. If this is the case, implementing the export as a codeunit (to which you could pass the record as a parameter) may be the solution, as you already mentioned.