Changes not committed to DB

eYeeYe Member Posts: 168
Hi,

NAV2009 SP1 database, hosted on native service.

The user creates a new Sales Quote:
1. No. is inserted from No. Series.
2. Lookup and select Sell-to Cust. - Click on different field to make sure value is entered.
3. Attempt to insert item no. on sales line - System raises error: You must specify Sell-to Customer No. in Sales Header...

After further investigation I found that when doing up to step 2 and then moving to a different document and then back, only the Document No. is filled in.
Verified with debugger on, that there is no error ( ERROR('') ).
It is standard code - debugged through whole process.
User has permission to insert, modify and delete Sales Header.

Now weird part - this does not happen when using user with SUPER role. BUT I copied the database to my local machine, using the same license, login and everything - don't get the error.
Even deleted the zup file - no success.

What did work was after step 2, to modify or validate another field on the Sales Header...

Any suggestions please?
Kind Regards,
Ewald Venter

Answers

  • ChinmoyChinmoy Member Posts: 359
    I do not have SP1 database anymore. My version is R2 now. It is still very weird though.

    When you debugged, did you notice anything wrong? Did the OnValidate trigger of the Sell-to Customer No. fire during debugging or it was by-passed?

    I was not able to simulate anything like this.

    Chn
  • eYeeYe Member Posts: 168
    I think I sorted it thanks. Waiting for confirmation from client.

    I noted that the database has NAV4.01 objects but running NAV6.01 executable (thus only a technical upgrade was done).

    So I recompiled all the objects and from what I can tell it seems to be working now.

    (Spent 2.5 hours on analysis, in the end 10sec recompile is the solution ](*,) )
    Kind Regards,
    Ewald Venter
  • andreaskellerandreaskeller Member Posts: 11
    I had the exact same problem after an upgrade from NAV4.01. Recompiling the objects did not work. Because of another error message we added read permission for the record link table for all users and also this error was fixed. The weird thing is that the customer says the day before all was working perfectly and apparently nobody has changed permissions.

    Andreas
Sign In or Register to comment.