This is a reposting of an article Dave Dusek originally wrote on my Developing for Dynamics GP blog.
This blog post is about a Dexterity support incident that I recently had that ended up to be more difficult than I originally thought. This one should have been easy, when a chunk doesn’t merge, it’s usually always easy. Except this case. The background is the following.
A Dexterity incident came in and the issue they were seeing was that the developer built a chunk file and when they copied the chunk file into their GP folder, the chunk wasn’t merging. No error or anything like that, it would never come up and ask you to merge the chunk file. So that’s how it started.
I’ve seen enough of these cases to know what to look for. Here’s the checklist:
- Check the name of the chunk file. To the left of the period, there can only be eight characters, to the right there should be 3 and they should be cnk. If there is more than eight or three, it won’t merge and will just be ignored. This is the problem 49% of the time.
- Check the version. The major, minor numbers must be the same and build numbers on the chunk must be greater than or equal to the dictionary that is there. This would only be an issue if the your dictionary is in the GP folder – if it was previously merged. This the the problem 49% of the time.
- When you build the chunk, in the Product Information window, make sure you are putting in Dynamics.set for the launch file. This field is used to determine when to merge the chunk. If Dynamics.set is misspelled or something else put in, then the chunk won’t merge. This is the problem 2% of the time.
So that’s 100%, we should have it nailed.
The problem is that the developer comes back and says the name of the chunk does follow the 8.3 format, the version isn’t an issue because the chunk had not been previously merged so the product dictionary isn’t there and the product isn’t in the set file. To top that off, they have a macro to build the chunk and the launch file is definitely Dynamics.set.
The next step for me then is to have the developer send me the chunk and I’ll try it on my machine. So they did. The chunk name was EFGSOPPO.cnk. So I put the chunk in on my machine and it works fine. So now it has to be an environment issue because it works for me.
At this point we do a screen sharing session so I can see what is going on. We drop the chunk in – same chunk they sent me. I check the dex.ini and check for the line:
That line doesn’t exist. We launch GP by dragging the dynamics.set on top of the dynamics.exe. This way we verify we are launching GP from the directory of the chunk. Sure enough, the chunk doesn’t ask to merge as GP launches. There isn’t an error or anything and it definitely didn’t merge it because it is not in the set file and the chunk is still in the directory.
So now what? Every reason that a chunk won’t merge has been covered. It works for me so I know the chunk is solid. The only thing I can think of is to try renaming the chunk. It’s called EFGSOPPO.cnk so we rename it to TEST.cnk. Still won’t merge. We rename it to EFG.cnk and it merges! So we got it to merge by renaming it to EFG.cnk, but why does that matter? The name EFGSOPPO.cnk is certainly valid.
So now we remove the product from the set file and get everything set back. We download my old friend Process Monitor from the Windows Sysinternals site. We put the EFGSOPPO.cnk back in and turn on procmon.exe. We launch GP and after it doesn’t merge, we shut off Process Monitor. We then disengage the screen sharing session and they send me the log file.
While I’m looking through the log file, in the File System Activity section, I can see Dexterity doing a directory query for C:Program FilesMicrosoft DynamicsGP*.cnk. That is the correct location. Then I see something interesting, Dexterity is finding a file called EFGABCPO.CNKHOLD! After that, in the log file, it never looks for any other chunk file. So now we have an idea of what is going on here.
Dexterity is trying to merge the EFGABCPO.CNKHOLD and the naming convention doesn’t follow the 8.3 format, so it fails. The problem isn’t with the chunk we are working with – it’s with a chunk that was in the directory, and was renamed for some reason. Once Dexterity fails loading a chunk, it doesn’t go on to the next chunk, it is just done. So that’s what was happening. We removed the EFGABCPO.CNKHOLD from the GP directory and everything then works as expected, the EFGSOPPO.cnk works as is.
The reason the renamed EFG.cnk worked was because unwittingly, we now put EFG.cnk alphabetically in front of EFGABCPO.CNKHOLD. So then it worked. Our regular chunk, EFGSOPPO.cnk and TEST.CNK came after EFGABCPO.CNKHOLD so they wouldn’t merge. So now it becomes clear.
Once again, Process Monitor helped me to see what was going on in the file system and from the clues there, we were able to figure out the issue. The issue turned out to be one of the main causes, problem was it was on a chunk in the directory that we weren’t working with. Things come from all angles when you work in a support role.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.