Already massive fraud detected in Michigan early voting
(twitter.com)
You're viewing a single comment thread. View all comments, or full comment thread.
Comments (23)
sorted by:
Someone want to play the devil's advocate and give any reason this isn't what it look like?
Possibly the database has all the previous addresses for a voter and this table is pulling data from multiple sources.
So you have a database of "voter ID / voted on" with one record. And a "voter ID / address / date of address" with all their old addresses ("urban" people get evicted and move around a lot).
Then you combine them and get a list of addresses and votes, but the votes are all referring to one vote.
Looks like you're right : from trmp's team.
Cool, what about the other hundred and fifty thousand?
There's two options:
Purge the duplicate data (kind of hinky and not that thorough in fixing problems, can cause other issues and may take too long, doesn't make sense for something like this)
Fix the base query that's used for the procedure/job to find and check confirmed vote (robust, solves the issue across the board especially if it's a query that's repeatedly used for a core process)
If the "glitch" (the proper term is "programming error" or "bug") was resolved through the second option, then it should be resolved for the "other hundred and fifty thousand" goalpost move as well.
Should also note back to fauxgnaws said
Voter ID here is likely a unique value in a column (maybe an incremented insert). You can't have 29 rows in the query pull with the same ID and the same date recorded, only one of those will get counted on any "Distinct" query of the Voter ID column. (e.g. SE\LECT DISTINCT VoterID, RecordedDate)
There's other ways to commit fraud instead of obviously bad UNION ALL statements.