Perhaps, you don’t fear ghosts. You just aren’t the sort of person who grew up feeling fear. While the supernatural horror movies may not scare you, I can tell you one thing that will cause you terror — the amount of time that you will spend deleting phantom data sources in the AOT to make your Microsoft updates work. Microsoft has written about this but I thought that I would repeat the warning as this is a common ‘gotcha’ when you do an update or uninstall a component of code (model). The first time that you deal with it, it will cause you to nearly lose your hair trying to figure out what is wrong.

After that, you figure it out (though it is in none of the Microsoft update guides) but learn to fear it for a whole new reason – the amount of time it takes to get everything fixed. Or, perhaps what is even worse, the number of implementers who don’t understand the issue so they just leave it alone causing all kinds of serious problems on the implementation, resulting in people like myself having to come in and fix it.

Let’s look at the problem of the ‘Phantom’ data source in AX.

Real World Case: You’ve made some sort of update to your AX implementation like a CU update or hotfix or you’ve added some code (like a model). Suddenly, you end up with a series of errors like this one:

Now, the solution for this usually goes the way. You have to open up your AOT, find each and every one of the little elements referred to with the errors and delete them from a lower layer (usually the one you are logged into). For the sysinethtml errors, that is usually fixed by rerunning the update utility against the Kernel, not database.

And here is how you fix the phantom data source. Simply find it in the AOT, and hit delete at the lower layer (such as USR).

And you continue to do that for hours on end until you’ve eliminated all the phantom data sources. Yes, it is manual and it can take a lot of time, but you just come to accept it with experience. Sometimes, companys ask me when I’m on site: “Brandon, will Microsoft warranty us if something happens bad from deleting the phantom data sources?” The answer I always tell them is “no”, which is why you need to do this in a development environment and test .. And yes, it will take some time – sometimes a full day to go through and reconcile everything once you know how to fix it. But it is worth it.

SADLY, I’ve run into this problem a lot on assignments where well-meaning companies were told by implementers that it was okay to ignore these sorts of issues and let the application not fully compile. That is not right, it just meant that the implementers did not understand the problem and did some ‘wishy-washy’ work. Don’t ever do that. If your application is not compiling than call Microsoft or somebody and spend the money for support if your implementer tells you that is okay for an application to not compile or to have synchronization errors on the production system.

So, for that somebody who is newer to AX and runs into this for the first time, remember it is normal. Just know what it is, roll up your sleeves, and get it fixed( usually by deleting the Phantoms like I just did).