Chinese characters being sent to TmpV2
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
- run query 1_Chinese_Checker in TmpV2_1.mdb
- if there are entries, the error has happened;
- if the error has happened, retrieve the correct entries from Centralized_data.mdb and fix in TmpV2_1.mdb
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)
- Template:Discussionif 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.mdb 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).
- 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)
- Template:Discussionif 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)
Occurrence Log
- February 7.14
- GRA-N3-problem reoccurring in the comment field in TMPV2. Trish Ostryzniuk 16:25, 2014 February 9 (CST)
- December 31, 2014
- HSC_B3_D5
- August 20.13
- GRA/MED-N3-Batch#32
- Pagasa Torres made changes to Centralized data.mdb and RESENT the data herself from backup of GRA_N3 ccmdb.data.mdb that is store on the Regional Server in the output folder. She also Cleaned up other database where duplicate were sent to.
- emailed Stephanie Cortilet to find out if she has any idea why. Ttenbergen 09:25, 2013 August 22 (CDT)
- Pagasa Torres made changes to Centralized data.mdb and RESENT the data herself from backup of GRA_N3 ccmdb.data.mdb that is store on the Regional Server in the output folder. She also Cleaned up other database where duplicate were sent to.
- GRA/MED-N3-Batch#32
- 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 Lou: "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?
- 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)
- HSC/B3-D5 Batch#33
- 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.
- Trish and Sheila R have Resent the files from backup for:
- STB_CICU & HSC_B3/D5:
- June 11.13
- GRA_N3, HSC_B3/D5
- June 6.13
- VIC_S4
- June 5.13
- HSC_SICU,(not sure why SICU affected)
- GRA_N3, STB_E5