Be sure to consider temporary tables as you create event subscriptions

oki

Temporary tables of NAV standard tables are often used to store a subset of records to be able of changing some non-primary-key field values for later processing. This is why marking the records is not the solution.

After the event subscribers have come into life, these functions !always! fire on each Insert, Modify, Rename and Delete with or without the function parameter (TRUE).

Imagine, you as the subscriber -for instance- hang on the Delete event and want to delete your 2nd level detail table data in a header-line-relation you always try to delete real records, no matter wether someone deletes records from his temp table!

This is obviously very very dangerous, even if there are actually no temp tables used.
Because in the future, someone could come to the idea and f#*@, data will be deleted and lost out of the control of the developer using the temp table.

So the solution is:
Every time you subscribe to the modification triggers above, your first source code line should be

IF <table>.ISTEMPORARY THEN EXIT;

In my opinion, it will be much more safer, if you use it everywhere on all subscriptions.

Hint:
If you're intend to use a temp table of a NAV standard table and have 3rd-party tools/products, ask all these companies, if they have considered the temp table problem in their coding.

@Microsoft:
Would it be reasonable that NAV only fires a subscription event if it's based on a real table?

Oki

Slawek_Guzek

oki wrote: »

@Microsoft:
Would it be reasonable that NAV only fires a subscription event if it's based on a real table?

Certainly not.

This is a developer and should be the developer decision to handle an event for a temp table or not.

I can come up, and in fact did have a few scenarios where events shoud handle certain scenarios regardless the table is declared as a temporary, or not.

This one liner:

IF <table>.ISTEMPORARY THEN EXIT;

is simple enough to be included on every event trigger which is not supposed to be executed on temporary table,

Imho you shoud not propose a solution limiting the choice for good developers because a few less experienced developers make mistakes. The way forward is to teach them good practices - just like you have just done.

Slawek

oki

I'm with you, if you are the developer who writes subscriptions.
On the other side, and that is the problem, the developer who just begin to use a temp variable in his code cannot see, what NAV or 3rd-party subscriptions are doing or will be doing (when installed in future) in modules in secured no. series.
If you want to avoid this risk, you have to create own table objects (cloned with all code removed) and take these for temp table processing. On each update these tables must then be checked if the NAV standard has changed them.
And more: There is no guarantee that all 3rd-parties do their job well, you can only hope.

Slawek_Guzek

What you are proposiong is like banning EVERYBODY to drive more than 30mph because there are a few inexperienced ones who have just got their licenses and cannot drive safely more than 30mph.

How do you like this? Surely you would avoid the risk on roads.

I believe before a in-house developed solution becomes an app it is supposed to go through Microsoft's certification. Part of this certification is (or it is supposed to be) checking for the code quality. IMHO this is where stuff like IF ISTEMPORARY... on event handler should be checked, or lack of it questioned by Microsoft.

For in-house solutions surely a partner has a control over the source code and bugs like ones caused by executing event handler on an event fired from a temporary table can and should be addressed.

Slawek

latronamarran

frankly i didn't knew that temporary tables are triggered by events. thanks for the info oki.
maybe it'll be better to have a property for the functions like "includetemptables" rather than ruled them out completely, our write a code line for every event function.