QUESTION
How do EDL and ERS keep track of their database version and what is the process for doing this?
ANSWER
Since EDL and ERS share the same database (EDL is typically loading data and ERS is typically reporting data), they both need to know about changes that occur to the database schema. Otherwise, one could be expecting a field that the other doesn't know about, causing unnecessary bugs and confusion. Since the beginning, they have both adhered to a versioning standard to keep them in sync. This is true for both EDL vs. ERS as well as multiple copies of EDL or ERS that are operating on the same database.
The database version number consists of three parts (major, minor, and revision) separated by periods (ex: 1.4.9).
When the 1st or 2nd number changes, it is a change that affects backward compatibility within the software.
Example: 1.1.1 -> 1.2.1
In other words, the software is outdated when compared with the database. This is not common and only happens when a low level change is made to the database that affects the software. When this occurs, the software checks the database version on launch, notices that the software itself is out of date, and pops up a message telling the user that he must update the software to continue running it.
When the 3rd number changes, it is a change that will only affect new versions of the software. Example: 1.1.1 -> 1.1.2
In other words, the database is outdated when compared with the software. This is fairly typical and happens when we add a new piece of functionality to the software that requires storage in the database. We add tables and fields to accommodate the new functionality and increment the revision number. When the new revision of ERS is run, it checks the database version, realizes it needs to update the tables in order to run the new functionality, and pops a screen allowing the user to execute the update to the database to bring it up to date.
This versioning works well when there are (for example) 5 copies of ERS in a plant. The first one to upgrade finds a new version of the database and forces the database update to accommodate some new feature. As long as only the 3rd version number in the database is changing (i.e. 1.1.1 -> 1.1.2), the other copies of ERS can continue functioning without any problem. This is because they don't have the new functionality that needed the database change so they can continue on as they were.
PLEASE NOTE: This database version is an internal version number that represents a snapshot of the database schema (tables, fields, and relationships) at a point in time. Whenever Prolink adds a field or table to the database, the version number must be incremented so updates occur.
MORE INFORMATION
When either EDL or ERS creates a database automatically, it adds the qccadmin user to the database and sets it as a db_owner. This will allow the user to make changes to the structure of the database. This is recommended so updates are seamless and do not require IT assistance.