Skip to content

Try This One Weird Old Trick to Write NAV Records!

ArcherPoint’s technical staff pose questions, find answers, and share new discorveries about Microsoft Dynamics NAV

I understand that this is a trick that “they” don’t want you to know about, and I’ve heard that it cuts down a bit of your belly fat each day. I’m not sure who “they” are, and I certainly haven’t noticed any reduction in my own belly fat, but that’s still what I’ve heard.

Anyway, this is a trick I’ve been using for a while, probably since shortly after I started working with Microsoft Dynamics NAV (Navision) by pulling in lots of data from a legacy system via big dataports.

Sometimes when you’re writing records to NAV, you get an error message saying, “The record does not exist. [Primary key fields here]”. This is an error you get when things are coded to do a MODIFY on a record that hasn’t actually been written to the database yet. I thought of this because it actually happened the other day; a customer called me because their sales order import wasn’t working, running into this issue.

The rule I use ensures this error never comes up. But everyone doesn’t know about the rule, so I’m writing a blog entry about it to tell the whole world.

What’s the secret? It’s pretty simple, really. I generally start record writes with a RESET and then an INIT, and then I set the primary key fields. Remember that INIT doesn’t actually alter primary key values, so you have to blank those manually. Once I’ve got a good, empty record, I then set the primary key fields. And here’s the trick: Rather than setting the other fields, I do my INSERT operation immediately after I write the primary key fields.

After I’ve done the INSERT with the primary keys, I then write the remaining fields of the record by calling [record].VALIDATE([fieldname],[value]. I always try to call the validation triggers, even if there’s no code in them, because someone might add the code later. I will write the field directly without the validation logic if it blows up, though; this tends to be the exception rather than the rule.

When I’ve finished writing all of my fields, I finish up with a MODIFY operation to update the database.

If I’m working with a No. Series that’s setting a primary key field, then I generally want the field I’m setting via No. Series to be empty and then I run the INSERT operation with a TRUE parameter, since the appropriate No. Series is nearly always called during the OnInsert trigger. In the event that I can’t call the OnInsert trigger for some reason, I can get the next value from the No. Series by using the NoSeriesManagement codeunit.

The good thing about using this method is that even if there’s a MODIFY somewhere in the OnValidate logic, it won’t blow up on me. Also, it means that if some programmer in the future adds a MODIFY to an OnValidate trigger later, the write operations I’ve put in place will still work properly.

About the only time I wouldn’t recommend doing this is when you have a huge set of records to write, and transaction speed is paramount. But those scenarios tend to be the exception, rather than the rule.

So, next time you’re writing records, try this trick and see if it doesn’t work out for you. Happy NAV coding!

For more information or assistance with NAV development, read more ArcherPoint developer blogs or contact ArcherPoint.

Blog Tags: 



Validate also does secret stuff behind the scenes, like, strips trailing spaces. Not sure what else. But, it is a good habit to get into.

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube