Behavoir of Batch Processing
ta5
Member Posts: 1,164
Hi
I have a strange behavoir with a report.
Lets use a table called x with a primary key (int) named pk. The report should copy some or all records in table x.
If I write some code on "OnAfterGetRecord" the result is a kind of endless loop, since the newly inserted records are visible to the processing loop. I have a workaround (use a temp variable of the table) and copy them to a normal record variable. Anyway, this looks a bit strange to me. :? Last and not least I'm interested how commited und uncommited changes are visible (to the connection that has changed the data) in reports and codeunits.
Comments on this are very welcome.
Thomas
I have a strange behavoir with a report.
Lets use a table called x with a primary key (int) named pk. The report should copy some or all records in table x.
If I write some code on "OnAfterGetRecord" the result is a kind of endless loop, since the newly inserted records are visible to the processing loop. I have a workaround (use a temp variable of the table) and copy them to a normal record variable. Anyway, this looks a bit strange to me. :? Last and not least I'm interested how commited und uncommited changes are visible (to the connection that has changed the data) in reports and codeunits.
Comments on this are very welcome.
Thomas
0
Comments
-
You can perfrom that kind of implementation three ways:
1. by using a temp table and perform the insertions and at the end of the report to move them into the real rec
2. By using another variable of the same type to insert/modify the recs without the primary variable that you use in the loop to know about it. I think I have done it a couple of times, but in cu... Don't know if it will work in a report. Try it and tell me...
3. by distinct filter the NOT new recs in your record with a field like (new rec) and insert the recs with "new rec"=true and at the end of the report to modify those recs as "new rec"=false. (not a good way) :-#
Of course the second way (if it works) is the best and then the 1st is next...
As for the commited or uncommited changes they are visible to the client that loops, but if an error occurs they are rolled back... That is why you must be carefull when batch modifing or inserting recs with loops to exclude the recs you insert or modify to avoid endless loops...
I hope I helped a bit...0 -
Uncommited changes are visible within same transaction. And the behaviour is different between Native DB and MS SQL DB.0
-
-
You are right, as for inserting recs the use of a second var is not correct, I checked some of my old code and I have used it for modifing only...0
-
I have no links for you, but the main difference is between locking method of both systems. Native is using optimistic locking (versioning) and table locking and MS SQL is using table/page/record locking. And all differences are based on this...0
Categories
- All Categories
- 75 General
- 75 Announcements
- 66.7K Microsoft Dynamics NAV
- 18.8K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 610 NAV Courses, Exams & Certification
- 1.9K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 250 Dynamics CRM
- 102 Dynamics GP
- 6 Dynamics SL
- 1.5K Other
- 991 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 28 Design Patterns (General & Best Practices)
- Architectural Patterns
- 9 Design Patterns
- 4 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1K General Chat
- 1.6K Website
- 77 Testing
- 1.2K Download section
- 23 How Tos section
- 249 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions

