|
I am pretty sure I
got this figured...
Look at the Central
Count Status Report by Deck report on the main database, you will see 6
decks including decks 0 and 3 which were committed on December 31 2001.
Look at the
PServerLog.log file for the main database and you will see all 6 decks
transferred at the same time. The timestamp isn't human readable but trust
me they're are all Jan 3. Look at PosterLog.log January 07,2002 09.27.20
PM Backup, you'll see the same six decks get posted to the database at about the
same time.
On the advanced
database, look at the CC status report. There is only 4 decks there, all
created on the 3rd.
Now look at at the
advanced database PClientLog.log and note how helpful it is. (Its empty
for those playing along). Had it contained useful information, it would
show the 6 decks being sent that were received on the main database side all on
Jan 3rd.
Here is what
happened: 2 decks were run on the advanced computer on Dec 31, but they
were never uploaded to the host. Resetting on the advanced database clears
its local counters, but does not clear the pending queue. There they sat
in the queue until the 3rd. On the 3rd, 4 more decks were run, and
queued with the other 2. Finally the all 6 were transferred, and confusion
ensued.
Here is what we need
to do at minimum to fix this:
(1)
Fix GEMS so
that the regional client's pending queue is cleared with a reset
election.
(2) Make the
regional server/client logs better than useless.
We'll do this for
GEMS 1.17.22.
Finally, ensure that
part of their procedures are to (a) print zero reports on both the advanced and
main databases before any ballots are counted and (b) check the regional results
dialog on the advanced machine and check that there are no unexpected jobs
pending before counting starts.
Ken
Here
are the databases, both the Regional, and the Main, along with the Poster Log
Files. If you take a look at the
Advance Paper results in the Regional database, those are the correct
numbers. However, the Advance
Paper results in the Main database are 44 votes more. From looking at the GEMS Audit Log in
the Main database, it appears that they did do a Reset Election, which should
have put all totals back to 0.
Unfortunately, we did not print out a zero report before loading up the
Regional database results to the Main database. From the PServerLog in the Main
database, it looks like that their were other decks committed. Any
help???
Jeff
-----Original
Message-----
From: Jeff Hintz
[mailto:jhglobal@earthlink.net]
Sent: Thursday, January 10, 2002 5:32
PM
To: Support
Team
Subject: Extra results
for Johnson County, KS mock election
Johnson
County, KS had a mock election last week and we encountered extra results when
we did the final reporting.
However, I have not been able to reproduce it, nor track it
down.
This
is what they did. They have 2
Servers that are both networked together. 1 is used for the Election Day
Voting-(AVTS), and the other 1 is used for Paper Absentee-(AVOS-Central Count)
and Early Voting-(AVTS). However,
they have set up the Paper Absentee & Early Voting as a Region, then when
they are done counting the Paper Absentee & Early Voting, they transfer
those totals from that Region to the Main database. We scanned the Paper Absentee and
loaded up the Early Voting totals on the Server set up as the Region. We then transferred those results over
to the Main Server with the Main database on it. When we printed out results, we had
extra results within the Paper Absentee counter group. However, on the other Server set up as
the Region, the Paper Absentee results were correct. We did not print out a Zero Report
from the Main Server with the Main database before we transferred the results
from the Region, however within the Audit Log, it does show that the Main
database was Reset, which should have set all totals to
Zero.
Does
anyone have any idea what might have happened
here???
I can
get both the Main & Region database from them, along with any logs if
needed.
Jeff
|