Trapping Errors

Thinking caps needed! Here is the situation. We are using a product called Data Backbone to communicate with a companies Oracle financials system. With Data Backbone you can setup scheduled jobs that transfer data from Oracle into Navision. The problem is that there is obviously no validation on the records coming in which creates a problem. What we thought the best way to do this, was to have tables that were copies of the originals(i.e Interface Vendor is a copy of Vendor) as a temporary holding place. Then from there we can do the validates into the proper table. The following is an example from a case statement. What is happening here is that for all the records in the interface vendor table it will validate fields(the codeunit you see there) and supress any error messages. If the codeunit runs through ok it will insert the record into the Vendor table. If not then it will send out an email with the table and record where there was a problem. I was just wondering if there was a clever way to supress the error messages but be able to get information on what went wrong.(ie. Failed on validate("Unit of Measure);

 
CASE "Table ID" of 

  DATABASE::"Interface Vendor": 
    IF IntVendor.FIND('-') THEN
      REPEAT
        Vendor.TRANSFERFIELDS(IntVendor);
        COMMIT;
        IF CODEUNIT.RUN(CODEUNIT::"Transfer Vendor",Vendor) THEN BEGIN
          IF NOT Vendor.INSERT THEN
            Vendor.MODIFY;
          //IntVendor.DELETE;
        END ELSE BEGIN
          cnt := 0;
          ErrorTable := Vendor.TABLENAME;
          ErrorArray[ArrayCount] := IntVendor."No.";
          ErrorArray[ArrayCount] := IntVendor.Name;
          ErrorArray[ArrayCount] := IntVendor."Vendor Posting Group";
          ErrorArray[ArrayCount] := FORMAT(IntVendor.Blocked);
          ErrorArray[ArrayCount] := FORMAT(IntVendor."Created by DBB");
          ErrorArray[ArrayCount] := FORMAT(IntVendor."Date Created by DBB");
          ErrorArray[ArrayCount] := FORMAT(IntVendor."Time Created by DBB");
          SendErrorMail(ErrorArray);
        END;
      UNTIL IntVendor.NEXT =0;
END;

I hope that all made sense. Sorry about the code section. I don’t know how to get it to work, and I have no time to figure it out. Taylor McCartney Development Specialist CSB Systems tmccartney@csbsystems.com

Handling Errors/Exceptions has always been a pain in the ass in Navision. Mainly when it comes to VALIDATE a field, if there was the possiblity to use the IF statement in conjuntion with VALIDATE, you could easily solve your problem by doing something like : IF NOT SalesHeader.VALIDATE(“Sell-to Customer No.”, Cust_ID) THEN BEGIN Error_ID := 42; LogError(Error_ID, Cust_ID); END; Since it’s not possible to do so, you will have to do some modification on anything which will involved a user input (MESSAGE, ERROR, CONFIRM, FIELDERROR, etc,etc…) Check table 36 - Sales Header on the Onvalidate trigger for the Sell-to Customer No. They do something similar : IF HideValidationDialog THEN Confirmed := TRUE ELSE Confirmed := CONFIRM(‘Do you want to change %1?’,FALSE,FIELDNAME(“Sell-to Customer No.”)); However in your case this could be a hell of a job since sometimes the validation of a particular field could trigger the validation of 5 or more fields … ###### Tarek Demiati Freelance Navision Developer Email : tarek_demiati@ureach.com Phone : + 65 - 906 787 16

The same thing happens with batch posting. You post a batch of sales orders and find out that some were unable to be posted. To find out the problem you have to attempt to post each order individually to get the message. Navision works around this somewhat by providing test reports that can be run prior to posting to identify potential errors. Perhaps you could do something similar.

Jack, The problem with a test report(in this situation) is that the integration has to be seemless between the 2 systems. Meaning that the goal we are trying to acheive would be little to no user involvement when data transfer occurs. I failed to mention that these data transfers are setup to trigger at certain times and/or dates. Otherwise the user might be able to run such a report. Little piece of info I forgot to add. Sorry Taylor McCartney Development Specialist CSB Systems tmccartney@csbsystems.com