(Click on all images to enlarge.)
UPDATED at end.
Waukesha County Clerk Kathy Nickolaus (emph. added):
On election night, all the people that were to bring in spreadsheets, they were given a spreadsheet template. They were asked not to change that template. When the city of Brookfield results came in on election night, extra columns were put into that spreadsheet, which would have been a problem if I had tried to import that in. I saved them, but when I imported them into the Access database, I thought that they were saved at that time, and didn’t have any real reason to believe they weren’t.Here is a spreadsheet with a column heading and 29 fictional votes. The columns are vote number, who the ballot was cast for, and an alternate way of recording the vote: a simple “Yes/No” field for Prosser. Note that rows 23, 24 and 25 all have bad data (“oops”) in what should be a Yes/No column:
Let’s take Nickolaus’ second point first: that when she imported the records she had no reason to think it failed. What happens in Microsoft Access when importing data that has some bad data? How does Access respond when there’s a problem? I created a database with a table called “VoteTable” and tried to import the data I just created in Excel:
So it throws up a big warning that explicitly says not all the data was brought in! It also specifies the number of rows that were affected, asks if the user wants to continue, and defaults to No, as in “No - do not import the data.” Nickolaus should have seen a very similar prompt if there was a problem importing her data. (I suspect Microsoft would also have a word or two to say about the allegation that its database product allows imports to silently fail.)
Access doesn’t choke on the extra columns, it just doesn’t bring them in. If it’s got bad data, it will pop up a big error message saying as much. What kind of template was Nickolaus using that caused the entire import to fail, and how did she not get some kind of error?
Note also: There is no “Save” in any part of this process. Either the import succeeds or fails; if it fails it will pop up a message saying how many records were affected. There is no saving of anything though. ALSO: The underlying data (in the original spreadsheet) is not modified by this process, so it should be possible to go back to it and have a second look. That is, unless it was deleted or modified for some other reason.
Nickolaus could just be giving a non-technical explanation for a process she doesn’t completely understand. Fair enough. But what she said yesterday raises some questions that might deserve a little scrutiny.
UPDATE: Charles notes a layout that could produce the kind of failure Nickolaus claims. That said, the table in question would have had to allow null values in the “vote count” column (or - God help us - defaulted to 0, which is how Access usually sets numeric fields). It would’ve been easy to set it up to not allow that, but assume nothing right?
Also, it would have required no summary reports being reviewed before the totals were sent out; zero sums would have stood out pretty clearly. She would have had to just run the macros and blindly sent out the results without even looking at them. That would be not stupid, but negligent. It would also be consistent with the modern GOP’s utter contempt for governance.It wouldn’t do anything about the “save” issue, though. The originating spreadsheets would still have been unmodified, but at least we have a scenario that could partially explain what might have happened.
Thanks very much to Charles for passing along the example.