RapidStart – A Query to Check Your Errors

RapidStart Services is a useful tool to load data into Microsoft Dynamics NAV. You can use it not only for initial setup but also for mass updates. (Theoretically, you can also use it for regular interfaces, but I think there are better options.)

But as much as RapidStart is useful, it does have one major flaw: it has no comprehensive error report.

To solve this problem, I’ve developed a query for it. (If you want a copy, scroll down to the bottom of this post.)

In this post, I’ll walk through RapidStart’s error process, and then show you the query.

Let’s by setting up some sample data. I load five new vendors to the fictional MS Dynamics NAV CRONUS demonstration database.

To keep things simple, I use only four fields:

• Name
• Vendor Posting Group
• IRS 1099 Code.

I also set up a configuration package called “ERROR EXAMPLE” and added one table to it for Vendor.

And here are the four fields I care about:

Then, I export a sample spreadsheet to Excel. (I find this easier than creating the spreadsheet myself.)

Next, I create four sample records. The first record is good. The second record has a bad value in Vendor Posting Group. The third record has a bad value in IRS 1099 Code. The last and final record has bad values in both Vendor Posting Group and IRS 1099 Code:

Next, I import the data:

As you can see, errors aren’t identified at time of upload. But I can look at the package data and see all the records:

Next, I can click on Validate Relations to check the data.

And yes, I do indeed have errors:

But note that the system has identified four package errors, even though one of the records contained no error.

Let’s take a closer look at the errors to see what’s happening:

And we come to the error screen:

In order to see the error for each line, I need to highlight the line and click Show Error:

As expected, I have one error for TESTRICK.

Note that the system uses Error Text and Field Caption to indicate which field caused the error.

If I look at TESTALAN, I also find one error:

And I find two errors on TESTJOEL:

And that’s why the system returned a total of four package errors.

Also, note from this screenshot that you can’t add many columns to this screen—only Field Caption and Field Name, which doesn’t get you much.

One more note about fields and errors: In this case, Validate Relations gave us the exact fields that were causing the errors. But that’s not always the case. Sometimes, the fields are valid but combinations aren’t set up correctly in NAV. (I had an example of this last week and, of course, haven’t been able to recreate it. I’ll update this post when it happens again—as it surely will.)

Having walked you through this process, you can see a few issues with the error page:

• We can only see errors for one record at a time.
• While the system shows the field involved, the actual value is in the error text field. So, you can’t easily see what it is.
• When you’re converting thousands of records, one mistake in setup can create hundreds of error records.

The goal of my query is to generate a report that circumvents these issues.

Let me start with the query results, so you can see what they look like:

This query gives you Package Code, Table Name, the primary key for the record (assuming only one primary key—I can adjust the query for multiple column keys), Field Name causing the error, and Value in the field that’s causing the error.

You’ll also see we only have errors for records two, three and four, as record one had no errors. That’s good.

This query also makes it much easier to ask for all bad values for a given field, fix them and then reapply or reimport the data.

And now, here’s the query:

As with all of NAV, this query is written for a specific company. But I can create a stored procedure that will take the company as a parameter and create the query dynamically. If you’re interested, let me know.