2022-08 sending issues: Difference between revisions

Line 35:

== Background ==

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.

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]]

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

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.

@@ Line 35: / Line 35: @@
 == Background ==
-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.
+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]]
-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]].
+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.