The Company Information does not exist. Identification fields and values: Primary Key=''

lvanvugt

We have been getting this error message (see title) 3 times since we went live on NAV 2016 beginning of July this year.

The first time this happened the company information was gone and we had to create the record in TAB79 manually again. And during that day it happened again a couple of times.
Because of this issue we implemented an alternative SQL trigger on the Company Information table for the DELETE to disallow deletion of data in this table and also log a DELETE attempt.

Since then it happened twice again, being yesterday and 10 days ago. Due to our alternate SQL trigger the data was not deleted, but to be able to continue the service had to be restarted.

As no one in our operation is allowed to delete data in the Company Information table AND none of those allowed had been performing a manual delete AND there is no C/AL DELETE statement, the quest is: what on earth can be the cause of this delete action?
Anyone that experienced something similar?

As we have a hard time to reproduce this, I am calling on you. All tips are welcome. Thanx in advance.

Note: we have 4 service tiers running and this, so far, has only happened on one of the. The error occurs during the same execution of the same processes were a shipment document is printed and an address label is printed.

vaprog

Hi Luc,

Since you say there's no C/AL DELETE, it is likely deleted using a RecordRef.

Kowa

Maybe it's used as an intended temp variable somewhere (e.g. passed as a parameter to a function) with the usual DELETEALL, but the temporary property has not been set.

kylehardin

Use a tool like Prism or MergeTool to find all of the references to T79 in code. If you aren't very customized, it might also be worth looking at the release notes for the update rollups for 2016 to see if that is a known bug that has been fixed.

lvanvugt

Hey vaqprog, Kowa, kylehardin, thanx for your thoughts.

I have been using Prism for ages already (and Idyn's OMA) and of course applied them on this issue. No references to TAB79 with a DELETE(ALL).

I am indeed going to follow the RecordRef thought and study the release notes for the update rollups (which was also on my mind).

Keep you updated.

And ... any other brain dumps on the topic are still welcome.

[UPDATE 1]
Nothing mentioned in the release notes

[UPDATE 2]
DELETE(ALL) using RecordRef only found here and these clearly address other tables:

COD5303 CollectionElementRecRef.DELETE(TRUE);
COD5303 CollectionElementRecRef.DELETE(TRUE);
TAB130 RecRef.DELETE(TRUE);

Kowa

Maybe the record is deleted with a SQL query. DELETE TABLE may be blocked by the SQL trigger
but what about TRUNCATE TABLE or DROP TABLE? For these the trigger does not fire.
https://sqlwithmanoj.com/2009/02/22/difference-between-truncate-delete-and-drop-commands/

kylehardin

I don't know what your NAV permission sets are like, but it might be an option to remove all write and delete access to that table, even for the permission set SUPER. At least that way, whoever/whatever is trying the delete will get a permission error message.

kylehardin

And if you remove all write and delete access from everybody in NAV and the record still goes away, then we know it's a SQL problem. There are ways you can figure out who/what in SQL as well (I'm thinking a delete trigger, or removing delete permissions at a SQL level for that table).

lvanvugt

Kowa wrote: »

Maybe the record is deleted with a SQL query. ...

Thanx for bearing with me, Kowa. The deletion as such is no issue for now as we have safeguarded that fortunately (see my initial post).

kylehardin wrote: »

I don't know what your NAV permission sets are like, but it might be an option to remove all write and delete access to that table, even for the permission set SUPER. At least that way, whoever/whatever is trying the delete will get a permission error message.
...
And if you remove all write and delete access from everybody in NAV and the record still goes away, then we know it's a SQL problem. There are ways you can figure out who/what in SQL as well (I'm thinking a delete trigger, or removing delete permissions at a SQL level for that table).

Also to you, kylehardin, thanx ... useful option which might give us more insight. Going to try this most probably.
BTW: the SQL delete trigger is already blocked as I also pointed out above ...

Keep you updated.

Kishorm

@Luc_VanDyck not sure if you ever got to the bottom of this or not, if not then have you tried enabling Change Log? As I'm sure you already know with later versions of NAV this also logs changes made via code so may help identify when (and by whom) this is occurring and therefore may help identify the source of the problem.

Kowa

Kishorm wrote: »

@Luc_VanDyck not sure if you ever got to the bottom of this

It's "the other" Luc (van Vugt) who started this thread.

lvanvugt

Yes, he is; yes, he is.

lvanvugt

Kishorm wrote: »

... not sure if you ever got to the bottom of this or not, if not then have you tried enabling Change Log? ...

Thanx for your thoughts. Nope we never did get down to the bottom as the issue never occured again.
Probably due to the fact that we had our security fuly setup as off that moment. As we could not realy reproduce it before that and it didn't occur after that, we haven't spent any closer investigation.

For us: cased closed.