2022-08 sending issues

From CCMDB Wiki
Jump to navigation Jump to search


Legacy Content

This page contains Legacy Content.
  • Explanation: Fixed bug
  • Successor: No successor was entered

Click Expand to show legacy content.

The following laptops can't send until we have figured out how to send their stale data:

  • S4, S5, S6, S8, H6

The following laptops can send once Pagasa gives the go-ahead:

  • G789
  • H45789
  • S5679

Fix

  • Some collectors had not backed up before and after sending, so some records were not available to be re-sent from backup.
expand to see details   

Ccmdb_data.mdb files in \\ad.wrha.mb.ca\wrha\REGION\SHARED\ICU_DATA_COLLECTION\data\2022-08-15_resends that contain records that may have been sent and deleted by the collector already. I re-sent the records in the files in the "already reprocessed files" directory because I was reasonably sure that it was a file backed up immediately prior to sending, but the remaining files were less certain. We need to decide how we want to re-process these before those laptops can send.

  • files that were likely backed up in the morning from shift before - confirm with collector if that is what happened. If so, these can be re-sent as long as the laptop has not sent since
* Julie, Lisa, Pagasa and Tina discussed and decided Pagasa will re-send the earlier file of the following:
							sendDtTm
S5 – no immediate pre-send file, 10 14:40 or 11 7:14	2022-Aug-11 07:02
S6 – no immediate pre-send file, 10 15:34 or 11:12:51	2022-Aug-11 07:50
S4 – no immediate pre-send file, 11 14.47 ot 12 8:33	2022-Aug-12 07:48
H6 – no immediate pre-send file, 11 11:46 or 11 14:34	2022-Aug-11 14:28 - Lisa confirmed that the 11:46 file is the one to use. 

  • files that were backed up with no clear time relationship to the sending time; this could happen if Access is closed and collector then does other things before backing up and then sending:
* Julie, Lisa, Pagasa and Tina discussed and decided Lisa will follow up with the corresponding collectors and determine what needs to be done:
							sendDtTm
S4 – no immediate pre-send file, 12 8:33, no newer	2022-Aug-12 09:41
S8 – no immediate pre-send file, 12 6:45 or 12 13:22	2022-Aug-12 12:18 

Background

Wednesday 2022-08-10 Tina did some updates to Centralized_data.mdb and rolled them out, but the change was accidentally done on an outdated file. That file was returned to the server and collectors started sending to it. Because Pagasa was on vacation, it wasn't noticed until Monday Aug 15 that there were problems with the data.

Coincidentally, the accident of getting collectors to send to an older version of centralized than expected exposed a bug where records with recordstatus = "deleted" could be sent. This was addressed in CCMDB.accdb Change Log 2022#2022-08-15

We reverted to most recent prior backed up centralized_data file from 2022-8-7-10.57 and re-applied the updates.

To bring the file up to current we then attempted to re-send the data in the same sequence as it was sent, based on the pre-sending backup files. Of 14 sends that happened in this period, 6 didn`t have backups with time stamps immediately prior to sending'. Three of these may have been backed up immediately prior to sending since those stamps are based on last closing time rather than time copied, so would be stamped like that if ccmdb had not been opened since end of last shift. There is no central log of when the backup actually ran, but there is a log in the c:\ccmdb_data directory on the laptop that would tell.

Records that were re-sent were conclusive pre-sending backup could be found:

H9	2022-Aug-10 14:58	
G9	2022-Aug-10 15:08	
H8	2022-Aug-10 16:24	
S8	2022-Aug-11 13:11	
H5	2022-Aug-11 14:00	
H9	2022-Aug-11 15:20
H7	2022-Aug-11 15:22
S7	2022-Aug-12 07:49

Ccmdb_data.mdb files that needed re-sending are at \\ad.wrha.mb.ca\wrha\REGION\SHARED\ICU_DATA_COLLECTION\data\2022-08-15_resends but will be deleted when this is settled.

Related articles

Related articles: