Duplicate objects with different id's in different layers.. how to fix?

(0) Share

Report

Posted on by Community Member

I ran into this issue when trying to install AX 2009 SP1 RU8 because it can't compile a bunch of objects that look like below. So the best way I can describe this is as follows using bogus id's:

Name | Layer | Object ID

MyFunObj | bus | 22003

MyFunObj | var | 31002

MyFunObj | cus | 22003

MyFunObj | usr | 31002

To remove the first question of how this happened, well, I don't know as I wasn't around when they did the initial implimentation of the system. I have a theory that someone did the var/usr layers for some reason but then copied in the layer file for bus and perhaps cus? I don't know and I have no way to find out to be honest.

But to the question, has anyone ran into this issue before?

Things I've tried:

#1) I've tried to log into the layers, export the changes for that layer out, and then delete the changes on that layer. That fails as it says the methods don't match or that i have dup object id's and it's not possible.

#2) Using UtilUIElements I've tried to select an object that I know is bad (say usr layer one) and try to change the object id to be that of the bus layer's id. Once I've had the object selected and the id updated, and committed the change back, it still doesn't actually change the id at all upon re-selecting the object back. To verify it wasn't a caching issue, I've stopped the aos', deleted the cache file, and then restarted it and let it rebuild the cache. Still the Id is not changed even then.

#3) I'm trying to browse through the AOT NodeTree and do just like #2 via that, but it's a slower process to do this, no result yet.

Pending if #3 fails, option #4 is to make an attempt to extract each layer file out to an empty environment and then export the change out, delete out the objects there and then put the layer file back into the real environment... But I don't know if this is really possible to do?

Sooo, I'm hoping that someone out there has some other ideas on this that would work? Thanks!

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (0)

Martin Dráb 237,882 Most Valuable Professional on at

Like (0)

Report

Changing things in UtilIdElements is not a solution - it's based on information in layers, not the other way around.

I would really fix layers one by one, i.e. option #4. It's simple and safe - if you work with a single (custom) layer, there can't be any conflicts with other layers.

Was this reply helpful? Yes No
Tommy Skaue Moderator on at

Like (0)

Report

Jeff,

It appears to me like the BUS and CUS Version has been developed isolated from the Var and USR Version.

And then the final error is someone not fully understanding what the "Import With ID"-checkbox does.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

So I'm trying that idea out now, but I've ran into a small hiccup where one of the dup'd objects w/ diff id's is a configuration key and it's throwing a fit if I try to remove it as it wants to re-sync the db resulting in chages... Ideas? :\

Was this reply helpful? Yes No
Martin Dráb 237,882 Most Valuable Professional on at

Like (0)

Report

The best approach is doing all such things in an environment without data, so synchronization is not a problem at all. Install the layers to an environment with data only after you resolved all such issues.

Your other options are disabling synchronization (in Application.dbSynchronize()) and ignoring dropped data and recreating the database from a backup when you're done.

Was this reply helpful? Yes No
Jonathan Havard on at

Like (0)

Report

Tommy's explanation of how it happened seems reasonable.

Importing from a different environment (and thus, potentially different element ID) and importing with element IDs in an XPO move could cause this issue, because AX will try to resolve the object based on ID, rather than element name. This causes issues as you well know (because AX sometimes uses name and sometimes ID).

I agree with Martin's endorsement of plan #4 and the suggestion to do this in an environment without data.

So +1 to the information you've already been given. The resolution is to get the layers isolated and remove the USR, CUS, and VAR objects that are duplicates. Afterwards, reapply the highest-most customization to the appropriate layer.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Yea, I agree 100% and I'm slowly working through it... Soon I hope I can get time to make an empty enviro, but for the moment I have to limp through with what i have.

Good learning experience though, let me tell ya!!!

I'll post results of this soon!

Thanks again for all the info and input on what to try/do! :)

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

No real update on this as I've been fighting the good fight on a very odd workflow issue (I've stumped MS AX PFE's & Product team engineers so far :( )...

WHat I've ran into is that the CUS layer won't load for me and throws errors when it trys that it can't load the application correctly and i believe it's because of another product someone installed that has code trying to use something at a lower layer. So I'm trying to find a way to force a load without it trying to run this code just so i can save/strip out the code I need to remove for the dup objects.

Anyone have any more ideas? This is turning into a real pain! :\

Was this reply helpful? Yes No
Suggested answer

Jonathan Havard on at

Like (0)

Report

Hm, a couple of things come to mind.

Are you using a clean environment? If so are they on the same hotfix level?

Are you deleting your Application Object Index (*.aoi) file before you try to restart? If not, you should probably do that.

What scenario is it that you can't get to work? Are you trying to start the AOS with just SYS, SYP, and CUS?

Does it start with just SYS and SYP? Have you tried SYS SYP BUS?

If push comes to shove you could just XPO a project of the entire utility layer (with IDs), log into your clean environment in the same utility layer, import (with IDs) and then clean up any artifacts. That should give you a "pristine" CUS / VAR layer although it'll be slightly more work-intensive.

I would try a couple more things to get the layer idea to work, but if you can't get that working you could do it XPO style.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

I don't currently have access to a clean environment, I so wish I did!! :( I'm trying to work with our Sys Admin team to create one for me, but it's just another thing for them to do... Hoping one will have time to do so soon!

Yea I actually have a powershell script that shuts down the AOS instances, deletes the aoi, and restarts the services. It's pretty handy to have for sure but I have noticed it leaves a lot of inactive sessions in the system, not sure if I'm missing a shutdown step there that we don't know about yet.

I can't get sys, syp, and cus to work... I can do sys, syp and var/bus/usr (swap in any of them), just not cus.

I'll definitely keep that other idea in mind, just would hate to do that unless I have too! :\

That said, it may be the last ditch option I have. WIsh there was a way for you to just relink the object id's inside of AX, but it doesn't appear so.

Was this reply helpful? Yes No