We recently upgraded NAV to 3.60 but the database remains 2.60.B. We are getting an error message in codeunit 92 Post and Print Purchase orders. The code has not previously been modified. PurchHeader.COPY(Rec); Code; Rec := PurchHeader; Code() WITH PurchHeader DO BEGIN IF “Document Type” = “Document Type”::Order THEN BEGIN Selection := STRMENU(’&Receive,&Invoice,Receive &and Invoice’,3); IF Selection = 0 THEN EXIT; Receive := Selection IN [1,3]; Invoice := Selection IN [2,3]; END ELSE IF NOT CONFIRM( ‘Do you want to post and print the %1?’,FALSE, “Document Type”) THEN [}:)] EXIT; PurchPost.RUN(PurchHeader); For some unknown reason the error Purchase Header IV0312345 does not exsist when I am Posting purchase header IV0312348. The error occurs in the debugger where the little red devil is “Then”. It seems like the command PurchHeader.COPY(Rec); does not read the correct Purchase header in 3.60.
To understand the problem, did you try to create some “check points” like this: Ok := CONFIRM(‘Rec type: %1, no. %2’, TRUE, Rec.“Document Type”, Rec.“No.”); Ok := CONFIRM(‘PurchHeader type: %1, no. %2’, TRUE, PurchHeader.“Document Type”, PurchHeader.“No.”); Sometimes, when using that kind of “check points”, we discover that the error is not exactly where the debugger said it was.
Can you give me the complete loop of code between your first begin and end. I miss your end line.
I had a similar problem that we solved by installing HotFix 9. Hope that helps.
quote:
Originally posted by geo_love
I had a similar problem that we solved by installing HotFix 9. Hope that helps.
That is the solution! The problem is in a pointer in th fin.exe; not in the C/AL code. However, I suggest to rear the following: Loading...
Thanks Walter the message solves the problem. Hard to believe that MS has not fixed this bug. As we just installed last week.
quote:
Originally posted by mblauer
Thanks Walter the message solves the problem. Hard to believe that MS has not fixed this bug. As we just installed last week.
Welcome. You should blame your Solution Center for not providing the service packs. At least THEY should know…
Not sure if I agree that “blame” needs to be place, but I do agree that it is very odd that the NSC did not apply all HOT fixes before doing such an upgrade. Then again, we are looking at an end user that has access to the development tools. As we know, once an enduser has development tools, it is pretty hard for the NSC to then controll what is going on. In this case, blauer could clarify if they did the upgrade them selves?
quote:
Originally posted by David Singleton
Not sure if I agree that “blame” needs to be place, but I do agree that it is very odd that the NSC did not apply all HOT fixes before doing such an upgrade.
David, I agree not to apply the application hotfixes in that kind of upgrade. But as a KNOWN error in the CLIENT the NSC should give at least these hotfixes to the customer (like the damaged server.exe in version 2.01). Walter
Well… in a customized database is not usually as easy as just importing the new objects, but you’re having to apply the changes to the customized objects… and sometimes the customer is not either willing to pay that time, so the hotfixes are not applied…