2022-08 sending issues: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
mNo edit summary
Line 1: Line 1:
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 now send:
* G789
* H45789
* S5679


== outstanding tasks ==
== outstanding tasks ==
* re-send or otherwise re-proces additional records:
* Re-send or otherwise re-proces the remaining records; there are 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
:* 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
  sendDtTm
  sendDtTm

Revision as of 17:57, 2022 August 15

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 now send:

  • G789
  • H45789
  • S5679

outstanding tasks

  • Re-send or otherwise re-proces the remaining records; there are 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
							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
  • 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:
							sendDtTm
H6 – no immediate pre-send file, 11 11:46 or 11 14:34	2022-Aug-11 14:28
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.