Update sets are a great way to move configurations between instances. However, when using update sets, there are some pitfalls that can easily be fallen into.

The main issue that most developers face is what customization will be added to an update set. Not all changes to tables are added to update sets. Whether changes to a table are added to an update set or not depends on whether the records in the table are considered data or not. Tables that are considered as data are not added to an update set; as otherwise, update sets would be filled with unnecessary records. 

For example, if the incident table was included in update sets, any incidents modified or created in a development instance would be moved across to a production instance, which would not be a good idea. Most tables are included or excluded from update sets as you would expect, but some are not always obvious, so it is worth checking.

To avoid missing updates in our update sets or including updates we do not want, we can check to see which tables we are working with and send updates to an update set. To do this, we can look at the dictionary entry of the table we are working with.

From the list of dictionary entries for a table, we are interested in the record with a type of Collection. This gives the definition of the table and also holds the attributes for the table, which is what we need to look at. The attribute that adds updates to a table to update sets is called Update synch, and it needs to be true. Usually, if this attribute has been added it will be set to true, and if it is omitted then it will be false.

Let's have a look at the dictionary entry for the incident table shown in Figure 11.4:

As the incident table holds incident data, we do not want incident records in our update sets. As we can see, the Update synch attribute does not appear here, so any incidents we create or modify will not end up in the update set.

Now let's see the dictionary entry for client scripts. We can see this in Figure 11.5:

In the Attributes of the client script dictionary entry, we can see the Update synch attribute, and it is set to true. This means that client script records will be added to update sets.

One table that is not included in update sets that is often assumed to be included is the scheduled job table. Because most records containing script are added to update sets, this can often catch developers out. A scheduled job can be moved by exporting it to XML and importing it into another instance.

In contrast, the table that many developers do not realize will be added to update sets is the System Properties table. Sometimes settings for developer instances, such as notifications set up to stop notifications being sent out, can end up being transferred to a production instance by mistake. This is a pitfall I have seen a few times over the years.