2022-08 sending issues: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
Line 4: Line 4:
* process phi csvs
* process phi csvs
* roll all newest versions (after I hear from Pagasa that she has copied legacy)
* roll all newest versions (after I hear from Pagasa that she has copied legacy)
re-send or otherwise re-proces additional records:
* 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 ==
== Background ==

Revision as of 16:04, 2022 August 15

outstanding tasks

  • send as possible
  • process phi csvs
  • roll all newest versions (after I hear from Pagasa that she has copied legacy)

re-send or otherwise re-proces additional records:

  • 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.