Showing results for 
Search instead for 
Did you mean: 

"View Database Mappings" not reflecting the correct mappings after changing them.

Not applicable
11 1 6,548


When updating your database mappings on sites with the Nintex Workflow Site collection feature already activated you may find that your database mappings do not reflect the changes you made.

For example I created the new database named "Test_Database" and went to change my existing mapping to my new content database. Here is the mapping for my old content database:


I then changed the mapping to my new content database "Test_Database:


Upon reviewing my database mappings under the "View database mappings" sub menu I find that this change hasn't gone through:



This is due to what is stored in our Nintex Configuration Database and how those records get updated. I've gathered the tables in the database that connect our content databases and their site mappings in the Nintex configuration database:

The dbo.Database table

This table stores the Nintex database information and where they are stored. It also assigned them an ID so they can be mapped to sharepoint content databases.


The dbo.ContentDBMapping table

This table stores the mappings between the Sharepoint content databases and the Nintex content databases.


The dbo.Storage table

This table stores the mappings between site collections and Nintex Content databases.


These tables all interconnect with each other and help direct where Nintex Workflow data gets stored. As you can see above my database mappings are successfully pushed to the Nintex Config database. However, upon reviewing the dbo.Storage table the site mappings still reflect the old database.


To resolve this issue simply deactivate and reactivate the "Nintex Workflow 20XX" feature at the site collection level. This will update the database mappings in SQL as it will query your Nintex Workflow Config database to find out what Nintex Content database is mapped to the Sharepoint content database the site collection is using and update that record (or create it if it doesn't exist) in the dbo.Storage table.

1 Comment
Not applicable

Thanks a lot Andrew. Came across the exact same scenario and your suggestion helped. Ideally this issue should not come if we follow the right steps in configuration and moving the databases.