ArcherPoint Dynamics NAV Developer Digest - vol 182
The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.
As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.
FedEx and Dynamics NAV
Jamie posts, “Looking for help from anyone that has hooked up FedEx with NAV. FedEx has a link to ODBC or SQL, and scripts to pull the sales order ship-to address, then write back a master tracking number and freight cost. Has anyone done this before?
Tim wants to know if Jamie has their API available from their web site, if it’s available. Is this to a FedEx shipping computer that’s on the customer site, or something like that?
Kyle points out, “At the risk of calling attention to something you already know, we have ISV options that already do this, such as Lanham and ChargeLogic.
Tim further notes that it sounds like a Master Data error to push addresses to a FedEx machine. And agrees, “True that an ISV solution would likely be a better choice.”
Kyle adds that it already sounds like three interfaces: address verification, rate shopping, and shipment tracking numbers. “It was a long time ago, but I think we went down this road with another client. And they ended up buying a whole lot of development hours and then switching to eShip a couple of years later. Each year that FedEx updates their interfaces (which they do often), you get to develop again. I’m not saying this is a bad idea for this specific customer. I’m just saying there may be more behind this request than it seems.”
Transaction Types for Dynamics NAV Reports
Kyle wants to know if it is a good idea to always set the TransactionType for a report. He thinks it should be set to Snapshot most of the time (read-only and only committed data), unless you need uncommitted data too, in which case, use Browse. He continues with an explanation of each transaction type option for NAV reports.
Browse
This is a read-only transaction. Modifications cannot occur within the transaction. All read operations are performed with READ UNCOMMITTED locking. Therefore, no locks are added and locks that are added by other sessions are not honored. This means that the transaction may read uncommitted data.
For more information about READ UNCOMMITTED locking, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL) in the MSDN Library.
Snapshot
This is a read-only transaction. Modifications cannot occur within the transaction. All read operations are performed with REPEATABLE READ locking. Therefore, shared locks are added on all data and are maintained until the end of the transaction. This prevents other transactions from modifying any rows that have been read by the current transaction.
For more information about REPEATABLE READ locking, see SET TRANSACTION ISOLATION LEVEL (Transact-SQL) in the MSDN Library.
UpdateNoLocks
This is an update transaction. Modifications can occur within the transaction. All read operations are performed with READ UNCOMMITTED locking until the table is either modified by a write operation or locked with the LOCKTABLE Function (Record). From this point until the end of the transaction, all read operations are performed with UPDLOCK locking.
For more information about UPDLOCK locking, see Table Hints (Transact-SQL) in the MSDN Library.
This transaction type improves concurrency for all tables that users access within the transaction by delaying locking as much as it can. However, the disadvantage is that you must know when to lock the tables for the required transaction behavior.
This is the default transaction type if you have not specified a type with the CURRENTTRANSACTIONTYPE Function (Database).
Update
This is an update transaction. Modifications can occur within the transaction. All read operations are performed with REPEATABLE READ locking until the table is either modified by any write operation or locked with the LOCKTABLE function. From this point forward, all read operations are performed with UPDLOCK locking.
This transaction type provides full transaction isolation from the start of the transaction, regardless of the lock status of tables that users access within the transaction.
Matt T agrees that Snapshot probably is to set to Snapshot, but admits that it’s one of those properties everyone forgets about. “I know I have never changed it and I don’t think I have ever seen anyone else change it. Definitely curious as to what others think.”
Michael states that he wouldn’t use the iterative data item to write. “If a write was necessary, I’d retrieve that record by using a second variable to set filters on the primary key values and retrieve with FINDSET(TRUE).”
Tell us about your experience! Do you set the TransactionType on your Dynamics NAV reports? Or is this a “forgotten” setting?
Stay abreast of what is new in the Microsoft Dynamics NAV community and at ArcherPoint by subscribing to our monthly newsletter, Better Business, by completing the form in our Resource Center.
If you are interested in NAV development, be sure to see our collection of NAV Development Blogs.
Read the “How To” blogs from ArcherPoint for practical advice on using Microsoft Dynamics NAV.