Rolling out changes

From CCMDB Wiki

Changes to the master version of CCMDB.accdb needs to be tracked in the Change Log and rolled out to all locations.

Rolling out a change to the CCMDB.accdb

This includes changes to the s-tables, the graphical interface and the programming/logic. Usually all collectors are considered testers, but if special testing is desired, Beta testing can be used.

  1. Check at the top of Log to make sure no one else has un-rolled changes; if they are, coordinate with them
  2. Make sure the change is documented at the top of Log, individual changes can be marked minor; mark as not rolled out yet at top of heading
  3. Make sure the version in the version table in the program has been updated to the date of the first set of changes since the previous version; this field drives the version number collectors see on their main screen
  4. Copy the new version to the Master directory
    1. Open Regional Server\Programs\Master
    2. Rename the file CCMDB.accdb to version it, e.g. to CCMDB.accdb.pre_2010-01-03; this will also prevent opening it accidentally since it removes the file association with Microsoft Access
    3. Move the renamed file to the Versions folder
    4. Copy the new version of CCMDB.accdb to the Master directory
  5. Roll out the changes
    1. run the file updt_all.bat
    2. when the file is done, it will show a log; review if you want to or just close, it's really just for keeping track.
  6. update in Log that an update was rolled out; this edit should have minor edit un-checked.

Rolling out a change to CCMDB_data.mdb

This process only works if the laptop is attached to the network the first time CCMDB.accdb is started after the new version is downloaded. Data collectors need to be alerted of this.

This includes changes to the data structure that collected data is stored in, i.e. the l-tables.

When CCMDB.accdb starts the form Main Form is opened. It's open event triggers a call to VBA function Database_Starter() in module Global_, which in turn calls function DB_Converter module DB_Converter, which checks if the current version of the CCMDB_data.mdb is as stated in that code; if not it copies down a new version and transfers the data.

Of course this needs to be changed to accommodate the change in the data necessitated the change in the first place.

  1. make sure any changes are documented on the wiki, ie new articles for new fields.
  2. open CCMDB_data.mdb_Change_Log and document change
  3. add the fields/make the changes
  4. update version in table A_Info
  5. close and don't copy to server yet
  6. open CCMDB.accdb and Log
  7. change version in version table if not already done
  8. update the version number for ccmdb_data in Module DB_Converter, Sub Convert_DB
  9. check to make sure your specific change doesn't require other changes to DB_Converter
  10. consider whether the change will have an impact on the send queries or the structure of Centralized_data.mdb and fix if necessary
  11. Roll both CCMDB.accdb (see above) and CCMDB_data.mdb concurrently
    1. copy ccmdb_data.mdb to Regional Server\data\master
    2. add date to the end of the name as in existing file

Rolling out a change to Centralized_data_front_end.accdb

Set up the entire environment on your computer that is needed to run this.

  1. check Centralized data front end.accdb Change Log to make sure no one else has un-rolled changes; if they are, coordinate with them
  2. start logging change in Centralized data front end.accdb Change Log
  3. make the changes on your PC
  4. roll the update to the master location
  5. document in Centralized data front end.accdb Change Log that you rolled out

The next Pull will download the change to others.

Rolling out a change to Centralized_data.mdb

Any work on Centralized_data.mdb has to happen outside the send window.

Confirm with Pagasa that she will not need the data while you are working on it.

Make a copy of the file and rename it to have today's date as the ending, e.g. Centralized_Data.mdb_pre_2017-01-31, and move that copy to the archive folder in the same directory.

Move the file to your computer from the regional server. Do not copy it to prevent confusion with versions. You can use the Pull down centralized data.vbs script, but don't use the Copy here only centralized data.vbs because it copies from elsewhere.

Change the date in the version table to be the date you start this round of changes on.

Log any changes in Centralized data.mdb Change Log.

If the data structure has changed, consider if changes are consistent with

Compact/Repair the file.

Move the file back to its master directory.

Finalize Centralized data.mdb Change Log and let Pagasa know there was a change.