Chinese characters being sent to TmpV2

From CCMDB Wiki
Jump to navigation Jump to search 


No longer relevant, no longer using TmpV2_1.mdb

Intermittently, contents of all the com_var field (eg Postal code or overstay color) in TMPV2 are corrupted/scrambled into "Chinese characters" on send.

This started 2013-06-05. Initially the thought was that doing a compact on the data file before sending would fix the problem. CCMDB.mdb was updated as part of CCMDB.mdb_Change_Log_2013#ver_2013-06-10 to compact/repair to run each time the program is started. However, there appear to have been cases where the problem has happened even right after a compact.

Work-around

After each Send period, Pagasa will

We are planning to eliminate TmpV2_1.mdb when we move to centralized_data.mdb, so spending much more time on troubleshooting this right now would not be practical.

Troubleshooting Log

  • Confirmed that data is intact in centralized_data.mdb.
  • When problem came up again Feb 2014 had another look; the data in comment appear to be unicode characters, and a chrw() of the character reveals an incomplete incremental series, eg. 20134, 20135, 20137. Still no idea why this happens, though.
  • As of CCMDB.mdb_Change_Log_2013#ver_2013-08-12 all data incl. tmp will be sent to Centralized_data.mdb. For the moment this is in duplication of sending to TmpV2_1.mdb, but it will replace that process eventually. In the meantime I would be interested to see if, in the cases where Chinese characters are being sent, both targets get Chinese characters. Will check as I see an update in the occurrence log. Ttenbergen 11:03, 2013 August 29 (CDT)
    • if there is a problem in centralized and Pagasa has to edit or changed especially if there are lots of them to do, working in Access in TmpV2 or centralized, it is extremely slow to work with. This is a big concern that she has raise.Trish Ostryzniuk 11:11, 2013 August 29 (CDT)
      • I agree, this and the not-sending of some patients are my first priority to fix right now. However, I have never been able to duplicate this problem on my PC, so I can't tell if it is fixed other than it not popping up any longer. I am not ignoring this, really! Ttenbergen 11:14, 2013 August 29 (CDT)
      • when you say extremely slow, is that a question of the interface being tedious, or is the response of the program slow? Ttenbergen 11:14, 2013 August 29 (CDT)
        • response of the program........just opening, navigating and closing is very slow. TmpV2 is the worst one. The concern is adding Tmp stuff to centralized....response time to work in it is dreaded by processor.Trish Ostryzniuk 11:18, 2013 August 29 (CDT)
          • We should talk. Moving tmp to centralized should make things faster. Tmp as of now contains one line for each time the collector sends; in centralized it is only current contents of tmp. This means the file should grow more slowly. Also, I am starting to set up Centralized data front end.accdb so we can add some smarts to this to make Pagasa's work less tedious. Please let's discuss what is needed there. And, let me know if this is causing too much disruption to Pagasa and you want me to re-prioritize work (I will get back to that list now that the new repository is getting off the ground).

Occurrence Log

No additional occurrences since Ttenbergen 16:36, 2019 January 3 (CST)

  1. February 19.14
    • HSC-H4/H4H - problem reoccurring in the comment field in TMPV2
      • Pagasa re sent the files and cleaned up the duplicates.--PTorres 14:57, 2014 February 21 (CST)
  2. February 7.14
    • GRA-N3-problem reoccurring in the comment field in TMPV2. Trish Ostryzniuk 16:25, 2014 February 9 (CST)
  3. December 31, 2013
    • HSC_B3_D5
      • late discovery on Feb 10.14 (In order to get postal codes and overstay colors, requested of restore of backup from eHealth, Dec 28.13 and also another restore of backup after this date since color and postcode for a few of them not in the Dec 24.13 collector back up on this date.Trish Ostryzniuk 19:17, 2014 February 10 (CST)
  4. August 20.13
    • GRA/MED-N3-Batch#32
  5. August 14.13
    • HSC/B3-D5 Batch#33
      • no problems for a while, but today Lou had a chinese character in her send... I emailed her and Pagasa to find out if they have any idea why there were chinese characters... Ttenbergen 15:54, 2013 August 15 (CDT)
        • comment from Louise Lemoine: "When I came in to work Wed, I remember now that I did not fully shut down computer but just did my “News and Backup” and logged off. (Went to the biffy and forgot to totally shut down). I only noticed when I came in next day and didn’t have such a long start up time. Maybe this was the issue as it wouldn’t have booted up with the latest changes in CMDB or server?
  6. July 3.13
    • STB_CICU & HSC_B3/D5:
      • Trish and Sheila R have Resent the files from backup for:
        • STB CICU batch 21
        • HSC B3/D5 batch 27
        • Deleted files with chinese in comment column in tmpV2.
  7. June 11.13
    • GRA_N3, HSC_B3/D5
  8. June 6.13
    • VIC_S4
  9. June 5.13
    • HSC_SICU,(not sure why SICU affected)
    • GRA_N3, STB_E5
Retrieved from "https://ccmdb.kuality.ca/index.php?title=Chinese_characters_being_sent_to_TmpV2&oldid=134965"