Initialize model store when ID conflicts?

(0) Share

Report

Posted on by Shashi s

1,203

In one of the applications I found that the ID's are conflicting (data sync wouldnt work. It gave errors regarding the field already exists). Turned out that the field that existed had an ID in SQL dictionary which was of the new field in the model.

Only a model was imported, so the model store and database wasnt changed

The error was fixed by deleting the already existing field from the database, as there was no data in the table.

Environment: AX 2012 R2

Now, in another environment (AX 2012 R2 CU6), i found a similar issue while synchronizing, it was trying to rename a field to another which already existed. turns out there were ID issues again. the ID's in SQL dictionary were different to that in the model. Thankfully there were only about 7 - 8 such errors, and i manually fixed it in the database.

The thing that baffled me in this case was that all these fields belonged to a hotfix.

So my questions are:

What is the use of initialize model store?

Will it help if i have different ID's in the database vs the model?

Has anyone come across ID conflict issues in 2012 (We thought this was a thing of the past)

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (1)

Suggested answer

Denis Macchinetti 16,444 on at

Like (0)

Report

Hi Shashi

Usually this situation occur when you uninstall the model before to install the new one.

In this case the ID change.

Otherwise, during Model installation AX check the objects by OriginGUID or by Type, Name, and ParentID.

Anyway, I have faced myself this issue sometime.

I have read this white paper www.microsoft.com/.../details.aspx

May be can help you

Kind Regards

Was this reply helpful? Yes No
Suggested answer

Beat 1,006 on at

Like (0)

Report

Hi Sashi,

Sad to say that element ID still matters in certain places.

First you can get into trubbles when you uninstall a model and install it (or an other version of the model).

Proper way to do this (when you like to keep the data) to just import it over the existing. Additionnally there are switches to overwrite or replace models on axUtil.exe

However, if you uninstall a model you should do aos restart, compile and sync, before you install any other models. This to clean up the dictionary.

Secondly, still some element ID's are stored in DB, e.g. NumberSeq module or Batch.module.

The white paper mentioned by Denis will give you more details about populate code and data to certain environments.

Here axsyncautofix.codeplex.com there is a tool to help you clean up dictionary..

The initialize model store does not clean up dictionary, it is used in the process of populate an application version to a productive environment keeping the downtime as less as possible. The only process tuching the dictionary is sync db.

regards

Beat

Was this reply helpful? Yes No
Verified answer

Tommy Skaue Moderator on at

Like (0)

Report

You need to keep your IDs the same across the environments you expect to copy data between (eg PROD to TEST).

See my blog post here:

yetanotherdynamicsaxblog.blogspot.no/.../about-your-elements-origin-id-and-handle.html

Was this reply helpful? Yes No
Shashi s 1,203 on at

Like (0)

Report

Thanks everyone for your input.

So the ID conflict occurs in the SQLdictionary table rather than the modelstore itself, which is understandable.

I am not too sure how this error occured as i was bringing in a completely different model. The fields that were giving an error, were related to a microsoft hotfix. (probably if i dig into it, the model would have been installed and reinstalled for this to happen)

Regarding initialize-AxModelstore, technet.microsoft.com/.../hh433540.aspx, this link says that use it when "The schema of the model store does not match the default model store. "

Hence my query if this would fix it. (Not, because it would only concern itself to the model database)

At the moment, this is just a one off issue fixed manually, the tool mentioned above for axasyncautofix sounds good, but will stay off it for now.

The way i fixed it at the end was to keep the element ID on the SQL dictionary the same as that of the modelElement table. It was a bit tricky, but solved the issue.

Thanks everyone.

Was this reply helpful? Yes No