Hi everyone.
When I was going to open a new purchase order in my Navision 4.0, the program tell me that I have no permission to read the table Purchase Header Archive and I dont understand why because I had never this problem.
I have gone to the server and open directly that table and I see only one line… what this table for? and… anyone knows how can I resolve this problem?
Thanks a lot (and excuse for my english…)
If you haven’t permission to the table, you shouldn’t have any record in that table, as well as in “Purchase Line Archive”, “Document Dimension Archive” and… I don’t know.
How did that record get there?
I was in the purchase order, i openned it, i tried to change something in the header and the navision told me that it was no possible so I decide to close again the order.
After that I cannot open it again…
What is the use for The Purchase Header Archive?
thanks Anna
To save the original order before it is completely posted and deleted by the system, I suppose.
To get rid of the annoying record you need somebody with a full developer license who can delete it for you.
I can delete it directly in the table on the sql server but i dont know for sure if this will fix the problem… Would i be able to get in the purchase orders after deleting this line in Purchase Header Archive and Purchase Line ARchive?
Thanks a lot Anna
Purchase order archive is a granule that allows you to take snap shots of purchase orders (Sales Orders also).
if you haven’t got the granule in your license, you shouldn’t be able to get into the table either.
it is likely you have the license, but simply don’t have navison permissions setup on your userid to allow you to access it.
try adding the permission to table 5109 - Purchase header archive
and then see if you can open the PO. it may give a different permission error, since it accesses may tables, but you can then just keep adding the permissions until you have them all.
Most likely, someone enabled or went to the setup in the Relationship Management graule. The archiving function is part of the relationship management package in Navision.
If you did not purchase the granule, it’s possible that your solution provider accidentally set it up for you, in that case you’ll need to ask them to turn it off.
The most common reason I have seen for this error, is when a Developer or Consultant form the NSC comes on site, and connects to the database using their developer license, and starts doing some processing. The code checks license permission to see if you have access to the Archive module (which a developer license does), and creates an archive. This is a very common problem.
If your Microsoft partner has logged to your system recently, I would ask them if they had logged in with a developers license to the live system, andif yes, get them to come out and fix it.
I’ve seen an end user who did this just recently, no NSC interaction, swears blind he didn’t have a NSC license. Seems weird to see this twice in 5 weeks.
/TH
I have to agree with David. This has happened to one of my clients recently where a Developers Licence as been used and a Purchase Order has been printed. On the Option tab when printing, it defaults to Archive Document regardless of the RM Setup. Just run the table and delete the Archived Purchase Header as long as you have a Dev Licence.
Yes thats exactly the issue. You don’t have to change any settings, just run the same function you have done a hundred times, but this time with a different license and bamm the archive is created.
Thats sort of what you would expect them to say. [;)]
How many end users do think have access to a developer license, Really now. I hear this explanation all the time, it must be something you did wrong, when you were using that license you are not supposed to have, and there has to be little to no chance that it happens. This was not caused by an end user using a license he shouldn’t have, it may have been be a careless developer
Maybe you didn’t read my post, here it is again:
As you can see we are both in 100% agreement here [H]
David, I did read your post and thought we were in agreement, but then you added you next post
TonyH:
… an end user …, swears blind he didn’t have a NSC license. …
And you responded
Thats sort of what you would expect them to say. 
This is what I was responding to. That cheap shot, that yes we all know the end users lies about what they did,
that is what it sure sounded like what you were saying,
Personally, I would not expect a person to lie to me, maybe I am just naive, but I think people are generally honest, and my first thought is not they must be lying, and must be using an illegal license.
Sorry, I didn’t mean it to sound like that [:$] I definitely was not implying that someone was lying. just that you wouldn’t expect an end user to be accessing their database with a developer license and I meant in in jest (thus the smiley).
So lets go back to the point where we agreed, that if the end user license does not have access to the Archive Granule, then the most likely scenario is that the solution center were connected with a developer license, and accidentally created a record.
Again apologies to anyone offended by my comments.
Hi Guys, before the fur starts flying, I my particular case it was the NSC at fault. A support person RDP’d into the system and changed licences to look at a problem, printed the PO and that added the entry to the Archived PO table.
Glad the problem was solved, and we all can agree, users and developers can cause problems.
Sorry if I was too sensitive, but has an end users I often get the feeling that developers wished they could just eliminate end users and all their problems would be solved. Of course that would mean they had no jobs, since they would have nothing to do.
Now, sometimes you developers might feel I just wish you would all go away, but that is not the case, because you provide a valuable service that helps my business run. It is just the careless developer, I have problems with, one that logs into a live database, uses his license, and causes problems like this, because he clearly didn’t think through what he was doing.
As a general rule, we and our developer only make changes to the test database, if there is a specific problem with current data, we backup the live database, restore it to the test company, and that way the developer can make his fix there, test it out, and then if needed go into the live database. Which it sound like a process you may want to start following. The live database is the life blood of the company, it should be protected as well as possible, from both careless users and careless developers alike.