There is an entire voting district in Perak/Lumut/Sitiawan/Astaka, where there is only one voter, a 22-year-old female, on an air field, which is the only locality in the whole voting district.
It looks like an honest mistake by the SPR, which somehow orphaned an entire district code, and a single, newly registered voter, out on an isolated air port garden.
This is the only result when we search SPR-issued MS-Access database gazetted on 2008 Feb 5, to list all localities and all voters in the DM of 074/50/11:
Kodlokaliti | Negeri | NamaParlimen | NamaDUN | NamaDM | NoSiri | IC | NamaLokaliti |
0745011024 | Perak | Lumut | Sitiawan | Astaka | 2502 | 860513335894 | Tmn Lapangan Terbang |
In the result above, we have left out voter name (Nama), NoRumah, Tahunlahir, etc, to reduce the exposure of voters' privacy.
You can confirm this problem through SPR's voter verification Web page. However, for this voter alone, the SPR Website does not publish the parliamentary, DUN, DM, locality details. (The boxes are left blank).
Still, you will be able to find the erroneous details in the MS Access file of "PERAK2.mdb". We display the Kodlokaliti and NoSiri to help you confirm these cases if you are using SPR-published Access file. We have not confirmed this voter appears in the PDF file.
Key issue is rectifying the mistake and finding the source or procedure that led to this very odd mistake. Very often, an odd mistake is only the tip of the iceberg for an underlying problem.
- How did the mistake come about?
- What background data restructure inside SPR had created such a weird set of codes and specific locality name? Was there a major re-organization of locality division?
- Could it be the tip of an ice berg of other related errors?
- How is the problem DM related to another existing DM of 074/50/02 (vs this problematic 074/5011), also named Perak/Lumut/Sitiawan/Astaka?
- Why is there a gap in locality number between 074/50/02 and 074/50/11, both having the same parliamentary name, DUN name, and DM name? (See table below)
- Why are details partially missing from SPR verification page served by the SPR database server, when the info is apparently valid data base format, even if the information is logically erroneous? In contrast, why does the info remain inside the MS Access formatted data file when it can go missing from a Web database server?
- What is the nature of this "Tmn Lapangan Terbang"? Was it an old and abandoned locality/street, or a new and emerging residential street area?
- Overall, even if it was an honest mistake, what procedure and logical process had produced such a stark mistake?
Code | Negeri | Nama Parlimen | NamaDUN | NamaDM | TM |
074/50/01 | Perak | Lumut | Sitiawan | Sitiawan | Sekolah Menengah Kebangsaan Ahmad Boestamam, Sitia... |
074/50/02 | Perak | Lumut | Sitiawan | Astaka | Sekolah Menengah Kebangsaan Tok Perdana Sitiawan |
074/50/03 | Perak | Lumut | Sitiawan | Simpang Lima | Sekolah Jenis Kebangsaan (Cina) Simpang Lima |
074/50/04 | Perak | Lumut | Sitiawan | Pekan Gurney | Sekolah Jenis Kebangsaan (Cina) Pekan Gurney |
074/50/05 | Perak | Lumut | Sitiawan | Simpang Dua | Sekolah Jenis Kebangsaan (Cina) Chien Hua Simpang ... |
074/50/06 | Perak | Lumut | Sitiawan | Taman Pegawai | Sekolah Kebangsaan St. Francis Sitiawan |
074/50/07 | Perak | Lumut | Sitiawan | Kampong Koh Utara | Sekolah Menengah Kebangsaan Methodist (Acs) Sitiaw... |
074/50/08 | Perak | Lumut | Sitiawan | Kampong Koh Selatan | Sekolah Jenis Kebangsaan (Cina) Uk Dih Kampong Koh |
074/50/09 | Perak | Lumut | Sitiawan | Kampong China Utara | Sekolah Jenis Kebangsaan (Cina) Uk Ing Kampong Chi... |
074/50/10 | Perak | Lumut | Sitiawan | Kampong China Selatan | Sekolah Jenis Kebangsaan (Cina) Uk Ing Kampong Chi... |
074/50/11 | Perak | Lumut | Sitiawan | Astaka | Sekolah Menengah Kebangsaan Tok Perdana Sitiawan |
No comments:
Post a Comment