Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 300 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
"Restricted Record" table NAV 2017
Mauddib
Member Posts: 269
In the past, up to and including Navision 2015, I have had reports that did some pre-processing in Temporary Tables.
This included lines like TempResults.DELETEALL(FALSE);
And it was never an issue before.
Now suddenly in NAV2017 it is a problem because when I call the DELETEALL, the system automatically tries to delete records (even though there is none) from Table 1550 - "Restricted Record". The problem is one is not allowed modify the database with this report.
Changing the Transaction type property of the entire report from "Browse" to "Update" or "UpdateNoLocks" makes the problem go away of course, as now I am allowing the report to be modifying the real database.
But I would like to know why this is happening, can it be stopped, or are my only options to change the report?
OR would it be ok to change the Navision standard code line that does a DELETEALL(TRUE) on Table 1550 to IF NOT ISEMPTY THEN DELETEALL(TRUE) so the new code never actually runs?
What is this new trigger? Where is it being triggered in the first place? And is it another "bug" that MS are allowing it to be triggered on Temporary Table Variables? It looks like a feature that only makes any sense on REAL tables, not temporary ones.
This included lines like TempResults.DELETEALL(FALSE);
And it was never an issue before.
Now suddenly in NAV2017 it is a problem because when I call the DELETEALL, the system automatically tries to delete records (even though there is none) from Table 1550 - "Restricted Record". The problem is one is not allowed modify the database with this report.
Changing the Transaction type property of the entire report from "Browse" to "Update" or "UpdateNoLocks" makes the problem go away of course, as now I am allowing the report to be modifying the real database.
But I would like to know why this is happening, can it be stopped, or are my only options to change the report?
OR would it be ok to change the Navision standard code line that does a DELETEALL(TRUE) on Table 1550 to IF NOT ISEMPTY THEN DELETEALL(TRUE) so the new code never actually runs?
What is this new trigger? Where is it being triggered in the first place? And is it another "bug" that MS are allowing it to be triggered on Temporary Table Variables? It looks like a feature that only makes any sense on REAL tables, not temporary ones.
0
Best Answer
-
NavNab
Member Posts: 181
Hi,
If I understand you, I believe that the "DELETE" is triggered by some events.
If my assumption is correct, check if you have an event subscriber to OnAfterDelete or OnbeforeDelete of your table "Results". If any, try to add this code in the subscriber function.
If Rec.ISEMPTY THEN
EXIT;
Here is an example based on table 38
Also, double check that your "TempResults" is a temp table.
5
Answers
If I understand you, I believe that the "DELETE" is triggered by some events.
If my assumption is correct, check if you have an event subscriber to OnAfterDelete or OnbeforeDelete of your table "Results". If any, try to add this code in the subscriber function.
If Rec.ISEMPTY THEN
EXIT;
Here is an example based on table 38
Also, double check that your "TempResults" is a temp table.