|
Thanks Ken, I seen those extra decks also, and thought they had something to do with
the problem. Thanks again, Jeff -----Original
Message----- 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 -----Original
Message----- 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----- 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 |