Reverting back to an older version of CCMDB.accdb: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
(Created page with "Access databases can become corrupt. This page tells how to identify this and recover from it in our setting. Generally we don't troubleshoot these, we revert to an earlier working version, re-apply the changes as per Change log, and roll out the changes == Identifying a corrupted version == The following things might tell you that you have corrupted version. * error messages that sound IT related, and that are addressed not on this wiki spe...")
 
mNo edit summary
Line 4: Line 4:
The following things might tell you that you have corrupted version.  
The following things might tell you that you have corrupted version.  
* error messages that sound IT related, and that are addressed not on this wiki specifically when you search for the text
* error messages that sound IT related, and that are addressed not on this wiki specifically when you search for the text
* the file size is significantly different, usually larger; this means the regularly scheduled compact-repair isn't working, usually an early sign of corruption
* the file size is significantly different, usually larger (it is usually around 12-13,000 KB); this means the regularly scheduled compact-repair isn't working, usually an early sign of corruption
* [[CCMDB.accdb requires password when closing]]
* [[CCMDB.accdb requires password when closing]]
* Julie or Pagasa have problems with re-connecting


== Rolling out a change to the [[CCMDB.accdb]] ==
== Fixing the issue ==
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.
The only solution seems to be to revert to an earlier version and re-apply the changes that were done. If the changes were extensive it might be quicker to import the module/form/etc that was changed from the corrupted version, but that too can be tricky. This happens to Tina during programming about once a month, but isn't usually encountered by others since they don't work with the code or data structures.
# Check at the top of [[Log]] to make sure no one else has un-rolled changes; if they are, coordinate with them
* In the {{Regionalserver|Programs\Master\Versions"}}, check the previous versions for one that is a normal size
# 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
* close database if you currently have it open
# 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
* copy the clean version and put it on the desktop
# Copy the new version to the Master directory
* rename to CCMDB.accdb, removing the postfix we apply to old versions
## Open [[Regional Server]]\Programs\Master
* open this copy and test to make sure it doesn't have the problem
## 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
* reapply any changes (look at the [[Log]])
## Move the renamed file to the ''Versions'' folder
* copy this new version from the desktop and put it in the C:\ccmdb_program, overwriting the broken version that is currently there
## Copy the new version of CCMDB.accdb to the Master directory
* follow the usual steps for [[Rolling out changes]]
### open C:\ccmdb_program\ in explorer
### copy ccmbd.accdb
### open regional server\programs\master in explorer
### paste ccmdb.accdb
# Roll out the changes
## run the file '''[[updt_all.bat]]'''
## 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.
# update in [[Log]] that an update was rolled out; this edit should have minor edit un-checked.
 
 


The only solution seems to be to revert to an earlier version and re-apply the changes that were done. If the changes were extensive it might be quicker to import the module/form/etc that was changed from the corrupted version, but that too can be tricky. This happens to Tina during programming about once a month, but isn't usually encountered by others since they don't work with the code or data structures.
* Steps to Identify the latest clean version to revert to:
** In the regional server \\ad.wrha.mb.ca\WRHA\REGION\Shared\ICU_DATA_COLLECTION\Programs\Master\Versions, check the previous versions for one that may be larger than the others, it is usually around 12-13,000 KB, choose the most recent "normal" sized version based on this
** close database if you currently have it open
** copy the clean version and put it on the desktop
** rename to CCMDB.accdb, removing the postfix we apply to old versions
** open this copy and reapply any changes (look at the [[Log]])
** copy this new version from the desktop and put it in the C:\ccmdb_program, overwriting the broken version that is currently there
** follow the usual steps for [[Rolling out changes]]
== Related articles ==  
== Related articles ==  
{{Related Articles}}
{{Related Articles}}

Revision as of 09:50, 2024 October 8

Access databases can become corrupt. This page tells how to identify this and recover from it in our setting. Generally we don't troubleshoot these, we revert to an earlier working version, re-apply the changes as per Change log, and roll out the changes

Identifying a corrupted version

The following things might tell you that you have corrupted version.

  • error messages that sound IT related, and that are addressed not on this wiki specifically when you search for the text
  • the file size is significantly different, usually larger (it is usually around 12-13,000 KB); this means the regularly scheduled compact-repair isn't working, usually an early sign of corruption
  • CCMDB.accdb requires password when closing
  • Julie or Pagasa have problems with re-connecting

Fixing the issue

The only solution seems to be to revert to an earlier version and re-apply the changes that were done. If the changes were extensive it might be quicker to import the module/form/etc that was changed from the corrupted version, but that too can be tricky. This happens to Tina during programming about once a month, but isn't usually encountered by others since they don't work with the code or data structures.

  • In the Regional Server\Programs\Master\Versions" (full address: \\ad.wrha.mb.ca\WRHA\REGION\SHARED\ICU_DATA_COLLECTION\Programs\Master\Versions"), check the previous versions for one that is a normal size
  • close database if you currently have it open
  • copy the clean version and put it on the desktop
  • rename to CCMDB.accdb, removing the postfix we apply to old versions
  • open this copy and test to make sure it doesn't have the problem
  • reapply any changes (look at the Log)
  • copy this new version from the desktop and put it in the C:\ccmdb_program, overwriting the broken version that is currently there
  • follow the usual steps for Rolling out changes

Related articles

Related articles:
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Reverting_back_to_an_older_version_of_CCMDB.accdb&oldid=161838"