Skip to content

Easily Finding a Dimension Set ID in Microsoft Dynamics NAV...or Mr. Billion Goes to Washington

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

With the advent of the Dimension Set feature in Microsoft Dynamics NAV (Navision), it can be tricky to figure out how to change the Dimension Set ID assigned to a record in code or how to assign new dimensions to code. If you don’t know what you’re doing, you’ll spend a few hours writing stuff to go through all the possible dimension sets until you find just the right one, or your code determines that there isn’t a valid dimension set at all and you have to create one. But there’s a way easier way. It’s just a little obtuse.

If you look at the DimensionManagement codeunit, you’ll find a function called GetDimensionSetID. There’s only one line of code in this function, and it’s a call to the GetDimensionSetID function in the Dimension Set Entry table.

Dimension Set Entry.GetDimensionSetID is the function we’re looking for to get a Dimension Set ID. It has only one parameter: DimSetEntry, which is a record variable with a subtype of Dimension Set Entry. The GetDimensionSetID function actually doesn’t care about the current Dimension Set ID record that it’s attached to—you can do an INIT on a Dimension Set ID record variable and then call that variable’s GetDimensionSetID function and get perfectly valid results. Instead, GetDimensionSetID pays very close attention to the DimSetEntry parameter that you pass in.

You may have seen this function and figured that it was exactly what you were looking for, so you had your code load up a Dimension Set Entry table with the combination of dimensions you wanted an ID for and you passed it in. And then you may have gotten an error saying something like “Dimension Set ID must not be 0 in Dimension Set Entry . . . “ from the line of code in the function that runs TESTFIELD on Dimension Set ID for each record in your passed-in set.

The secret of using this function successfully is actually pretty simple. You have to pass it a temporary set of Dimension Set Entry records containing all the dimensions you’re trying to find a Dimension Set ID for, but you have to make sure that the Dimension Set ID value on all of your temporary records is -1. (I suspect you could use some other negative number, but I like -1 for the sake of consistency.) At least, that’s the way I do it when I’m trying to get a Dimension Set ID; giving the temporary records the -1 value lets me know what I’m doing if I see them in the debugger. (Also, should I forget to mark the temporary property on the record variable and end up writing those records to the real database, using the negative number makes them easy to identify as errors when I go look at the records.)

Video Gaming Update

And finally, because I know that people only read my blog entries to hear about me playing video games: After over 100 hours, I finished my first playthrough of Persona 4 on my PS Vita. I missed out on P4 when it was a PS2 game by virtue of not really having that much time to sit in front of my TV, but having that game in my pocket made it super-easy to find time to play. It’s an absolutely amazing game; it’s my favorite JRPG since Final Fantasy IX. If you like JRPGs, you should pick it up. (And if you’re curious, I wound up dating Rise—although I considered going with Yukiko instead.)

If you have any further questions about this or other development issues, contact one of our development experts at ArcherPoint. If you enjoyed this blog, you might like to read more of Tom Hunt’s blogs, or check out our collection of Development Blogs.

Blog Tags: 


PBA's picture


This is all fine if nothing was changed in the Dimension Set table. Sometimes still some Partners are making a huge mistake and are changing data manually. If you change anything in the Dimension Set Entry table then you create data inconsistency. There is funny thing, by making some changes in Dimension Set Entry table you can create a situation that, when the user opens Dimensions in any document, he can see 3 dimensions, and when he opens the same Dimensions again then he will see only 2 dimensions and when he opens the same Dimensions he will see again 3 dimensions. How does this happen? It is because NAV is using Dimension Set Tree Node to get the proper Dimension Set ID.

How do you check if your Dimension Set ID is correct? Just make a list of your dimensions from Dimension Set Entry table with Dimension Value ID's (you can get them from the Dimension Value table). Sort your values by Dimension Value ID's and take these few easy steps:

For example my Dimension Set ID is 15. My Dimension Values ID's are 1,8,11.

1.  Filter Dimension Set Tree View by: Parent Dimension Set ID = 0 and Dimension Value ID = your lowest id (mine is 1). I'm receiving the result: Parent = 0, Value ID = 1 and Set ID = 7.

2. Filter Parent Dimension Set ID by your previous Set ID (mine is 7) and Dimension value ID = your next Dimension Value ID (my is 8). I'm receiving the result: Parent = 7, Value ID = 8, and Set ID = 8.

3. Perform Step 2 as long as how many dimensions you have. My last step is filter Parent = 8, Value ID = 11 and I'm receiving result 15 as Dimension Set ID - this means that my Dimension Set is proper. 

There is a way to check this from other side also by filtering from your biggest Dimension Value ID (my 11) and Dimension Set ID (my 15) and just in another step filter by Dimension Set ID instead of Parent Dimension Set ID.

From this point there is an easy way to create a page which will show you both dimension sets (from Dimension Set Entry and Dimension Set Tree Node) by your Dimension Set ID and also to create a report which is checking dimension data consistency (I've created one with export to Excel).


This is great advice!  Thanks for sharing!

And I have to say it: Changing the Dimension Set Entries manually is incredibly dangerous and should only ever be done as a last resort. That's something that we should treat like manually changing records in the General Ledger Entry table--that is, we should do it rarely if ever, and only after we've exhausted all other options.

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