Transaction integrity

Fixing Preview Posting: Part 2

  • Post comments:16 Comments
  • Reading time:13 mins read

In my two last posts, I laid out the technical design of the Preview Posting feature, and then showed how to simplify its design to get around the unwanted behavior of TryFunction.

One thing is obvious from these posts: Preview Posting wants to simulate posting of a document (or journal) to show what the results would be, but without leaving any actual trace in the database. In database lingo – we want the transaction to be rolled back.

Rolling back is no brainer. Simply throw an error, or do a silent abort, Except if there is COMMIT. In that case, no rolling back helps.

I have announced earlier that my today’s post will be about how to nest transactions in C/AL so that an inner COMMIT has no effect on the transaction as a whole, which can still be successfully rolled back.

That’s what this post is about.

(more…)

Continue ReadingFixing Preview Posting: Part 2

TryFunction Lessons Learned from Preview Posting

  • Post comments:19 Comments
  • Reading time:11 mins read

One of great new functional features of Microsoft Dynamics NAV 2016 is preview posting. It allows you to preview all the entries that would result from posting a document or a general journal.

Preview posting is not a simple thing. If it was, Microsoft would have delivered it years ago. There must be something in particular with NAV 2016 that powers preview posting, so I decided to investigate it and see exactly how it works.

I am not particularly happy with what I found out, but I have also learned some valuable lessons from it. In this post, I’ll share my findings.

(more…)

Continue ReadingTryFunction Lessons Learned from Preview Posting

Transaction Integrity with Connected Systems

  • Post comments:3 Comments
  • Reading time:6 mins read

Broken pencilWith .NET Interoperability around, it’s very likely you’ll be synchronously calling external web services from C/AL, to exchange data. I won’t go into discussing whether or not this kind of architecture is good (my own position is that it isn’t), you may end up having situations where your C/AL code simply makes a synchronous call to external systems, such as web services.

Any external call is an expected point of failure. An important question you must always have in mind when calling external functions is transaction integrity. When writing code that targets only NAV, the structure of code is largely irrelevant, as long as you are not using COMMITs (which is another thing you should avoid at all costs). However, as soon as you introduce external calls, the structure becomes critically relevant. Critically relevant.

I’ve talked about this during my 2012 NAV TechDays session, and I promised I’d blog about it – so, here it goes.

(more…)

Continue ReadingTransaction Integrity with Connected Systems