Why have the ID numbers in the Events module jumped by 1,000?

Rarely, you may notice that the Event ID numbers in the Events module have jumped by around 1,000.

This is nothing to be concerned about and is the way an SQL Server can behave when the service is restarted.
The SQL server uses a cache size of 1,000 when allocating identity values in an integer column and restarting the service (e.g. for maintenance) can 'lose' unused values.

As an example, your highest Event ID in Damstra Safety may currently be 3255. The SQL Server may allocate the next 1,000 Event IDs up to 4256 for performance reasons. The values from 3256 to 4256 are now sitting in a cache waiting to be used. If the SQL Server is restarted the numbers in the cache are 'lost' and the SQL Server will continue from ID 4257.

Be assured that this isn't a result of a loss of data or an issue with Damstra Safety. It is merely the behaviour of the SQL Server and is not something that we have control over.

Additionally, we make no guarantees that every ID is used and that there won't be gaps. Furthermore, the ID should only ever be treated as an identifier or a 'name' for the event and not relied on for anything else.

Note: this can happen in other modules, not just the Events module