User settings and customization being deleted with every update.

(0) Share

Report

Posted on by Community Member

Can anyone explain to me possible reasons some users security settings and code customization's are being deleted from the production environment whenever new deployments are done? This is happening on a consistent basis with every update that is pushed through. I have tried contacting the partner, but to no avail. Does anyone have any ideas?

*This post is locked for comments

I have the same question (0)

All responses (7)

Answers (2)

Brandon Wiese 17,788 on at

Like (0)

Report

How are you "pushing through updates"? Are you referring to importing a new model store into your production environment?

It sounds to me like an Element ID/handle issue. It's very easy to get those out of whack without proper controls, and when they get out of whack exactly those kinds of things happen.

Was this reply helpful? Yes No
Brandon Wiese 17,788 on at

Like (0)

Report
You can check to see if you have any broken security references with the following SQL.

Execute this from your business database, but replace [YOURMODELSTORE] with the database name of the associated model store.

SELECT * FROM SECURITYUSERROLE r WHERE r.SECURITYROLE NOT IN (SELECT RECID FROM [YOURMODELSTORE].dbo.SECURITYROLE x)

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Brandon,

I used that as an expression. I am not really sure how they are doing their updates. All I know is that every time an update is done, data is lost. I explored the idea of Element ID's being replicated, or better said over written, but I have no way to confirm this. I am pretty sure this is what is going on, because this seems to be the most logical explanation. Thanks again for your help.

Was this reply helpful? Yes No
Verified answer

Brandon Wiese 17,788 on at

Like (0)

Report

I'm not sure I actually helped you. Element ID's are the most likely cause for what you seem to be observing. If Element ID's change underneath a system, a couple of things are likely to happen.

Data can be lost, as the database sync process interprets the change of ID as an old table needing dropped and a new table needing added, or a field as it may be. These are not Element ID's but actually Ax Id's, but the same concept.

More rarely things can break as Class ID's (which are just Element ID's) change, if they are referred to in record data.

Security can be lost, as the SecurityUserRole table refers to security roles directly through their Element ID's. I have actually had this happen to me during a long upgrade cycle (going from R2 to R3) where new security elements deployed to PROD and the new model store being built in parallel ultimately cannot have the same Element ID's no matter how good your controls are. The query I posted earlier should detect these, which would also serve as good evidence.

As far as code being lost, that's just poor controls in place. It sounds to me like perhaps you have many environments, likely even multiple development environments (which can make life really difficult).

I have written some SQL in the past to detect these Element ID problems. The Ax ID's are more easily detected because the mismatch is between the model store table ModelElements (Element type 45 I believe) and the SqlDictionary table.

Let me know if I can help more.

Was this reply helpful? Yes No
Verified answer

André Arnaud de Cal... 301,075 Super User 2025 Season 2 on at

Like (0)

Report

I have seen similar thing happening. At that time the customer developed security in the production environment. Then moved back to the development environment. Then it was moved to a staging evironment together with more customizations. From the staging the complete modelstore was moved to production. At that time indeed the staging had new element IDs which were moved to production causing this issue.

Ensure that you do not have new elements which could have dependencies on IDs in your production environment which can be overwritten later.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

You did Brandon, and I am grateful. Thank you!

Was this reply helpful? Yes No
Community Member on at

Like (1)

Report

Hi Andre,

I have a feeling that the ID's weren't controlled, and thus were over written. The scenario you described, I think is almost exactly what happened in this case. Thank you!

Was this reply helpful? Yes No