Codeunit.RUN error appears always

vjelkovvjelkov Member Posts: 3
Hello everybody,

i have a question about a weird behavior of NAV with version 5.0 or higher.
I have two codeunits - the first one is generating error when run by trying to add a record that already exists to a table. (In the example the Unit of Measure table). The second one is just calling the first one with Codeunit.RUN and checks the return parameter is the execution has failed or not. The result is that no matter I have used the return parameter in the second codeunit, a run-time error pops up.

The codeunits look like:
Codeunit 50002 - Error

OnRun()
uom.INIT;
uom.Code:='SOMETHING';
uom.INSERT;
Codeunit 50003 - Call Error

OnRun()
IF NOT CODEUNIT.RUN ( CODEUNIT::Error ) THEN
  MESSAGE ( 'There is problem.' ) ;

When Codeunit 50003 is run on Navision 4.03 it works as expected - shows the message.
On 5.0 SP1 (Build 30488) and on 6.0 R2 (Build 32012) it pops up run-time error.
The databases are on SQL Server 2008 R2 if maters.

If Transaction Type Snapshot or Browse is used, the code works as expected (the message is shown), but in these transaction types are read only.

Anyone having the same problem?

Answers

  • rdebathrdebath Member Posts: 383
    Your problem is the new (for V5) bulk insert functionality. Inserts that you don't check the return value of are delayed as long as they can be and sent in one go; in your case all the way to the COMMIT which is outside your codeunit.RUN.

    You need to force the update to happen within your "RUN". The obvious way to do this is to COMMIT before you exit the codeunit.RUN but this may not be what you need.

    The best possibility IMO would be a 'flush' method or command, but Microsoft NEVER think that far ahead.
    You might consider putting a request for that change.

    IMO the best you do is to call something that naturally flushes the queue to the database; I find countapprox is a nice one; like this:
    IF uom.COUNTAPPROX = 0 THEN; // Flush uom inserts.
    
    It's a simple command which is specifically designed to be fast and has the nice property that it sets no extra locks in itself.
    It's probably the best you'll get without a true 'Flush'.
  • vjelkovvjelkov Member Posts: 3
    Hi Robert,

    thank you for your reply.
    I realized that the COMMIT is the problem and as you say putting the COMMIT in the called codeunit was not a solution to the problem.
    The COUNTAPPROX itself works like a charm. =D>
Sign In or Register to comment.