DATABASE SYNCHRONIZING

When you add content nodes to the Umbraco CMS, they are assigned unique incremental numeric values. For example, if you are working off a blank Umbraco install, you may start with a Node ID of 1070 when you create your very first node in the system. As nodes are added this ID is incremented by one; the parent/child relationship between nodes has no impact on this numbering. A child node could have an ID of 1100, whereas its parent node may have an ID of 1085. It all depends on when the node was created and what the max ID number was at the time of creation. When Umbraco relates nodes to one another and when it stores the path to each node, these IDs play a very important role to the hierarchy of the website. So, keeping the IDs in sync from one environment to the next is important. To preserve this hierarchical relationship, the best practice is to synchronize the underlying database of your website whenever changes are made.

An example where synchronizing makes sense is when you need to add additional document types to your installation but need to retain changes made to the content tree. To preserve the content structure of the production website, you must first synchronize your development database with the latest information contained in production. When that is done, you can make the changes in development (add document type, create any required parent nodes, and so on), and then resync the production database after the changes have been made. In the event that the development process is too lengthy and changes have to be made to the content in production during this time, you would have to keep track of the changes and use a combination of manual updates and the packager (see the previous section) to make the changes and make sure they are synced in both environments.

The best practice for performing a hot sync of the database is to create a full backup of the site using SQL Server Management Studio Express (or the full version if you have access to that). The process creates a .bak file that you can use to simply restore the database in the target environment. Synchronizing the environments using this method allows you to operate without causing any intentional downtime.