2022-08 sending issues: Difference between revisions

From CCMDB Wiki
Jump to navigation Jump to search
← Older edit
PTorres (talk | contribs)
CCMDB_legit, approved
1,617 edits
No edit summary
m Text replacement - "[[Centralized_data.accdb" to "Centralized_data.accdb"
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Fixed bug}}
{{LegacyContent
| explanation=Fixed bug
| content=
The following laptops can't send until we have figured out how to send their stale data:  
The following laptops can't send until we have figured out how to send their stale data:  
* '''S4, S5, S6, S8, H6'''
* '''S4, S5, S6, S8, H6'''
Line 8: Line 13:


== Fix ==
== Fix ==
* We restored an earlier version of [[Centralized_data.mdb]] and re-sent the records that were sent while an outdated C was master.
* We restored an earlier version of [[Centralized_data.accdb]] and re-sent the records that were sent while an outdated [[Centralized_data.accdb]] was master.
 
{{Discuss | who = Pagasa | question =
* All that can be re-sent has been re-sent, right? If so I will clean up the \2022-08-15_resends directory. Yes, you can clean up. [[User:PTorres|PTorres]] 15:23, 2022 August 31 (CDT)
}}


* Some collectors had not backed up before and after sending, so some records were not available to be re-sent from backup.  
* Some collectors had not backed up before and after sending, so some records were not available to be re-sent from backup.  
{{Todo
| who = Tina
| todo_added = 2022-08-25
| todo_action = 2022-08-25
| question = 
* Tina has meeting booked with Mailah next time that laptop is used. We will reclaim what data we can from deleted records, but these records will basically need to be re-coded. [[User:Ttenbergen|Ttenbergen]] 16:34, 2022 August 25 (CDT) }}


{{Collapsable| always =  expand to see details | full =
{{Collapsable| always =  expand to see details | full =
Line 40: Line 35:


== Background ==
== Background ==
Wednesday 2022-08-10 Tina did some [[Centralized data.mdb Change Log#2022-08-10| 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.  
Wednesday 2022-08-10 Tina did some [[Centralized_data.accdb]] Change Log#2022-08-10| updates]] to [[Centralized_data.accdb]] 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]]
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 [[Centralized data.mdb Change Log#2022-08-15| updates]].  
We reverted to most recent prior backed up centralized_data file from '''2022-8-7-10.57''' and re-applied the [[Centralized_data.accdb]] Change Log#2022-08-15| 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.  
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.  
Line 59: Line 54:


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

Latest revision as of 10:40, 24 July 2025


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 Centralized_data.accdb Change Log#2022-08-10

Retrieved from "https://ccmdb.kuality.ca/index.php?title=2022-08_sending_issues&oldid=165592"