Mark - you've recently released the new reports showing the sequences by captain for winning & losing the toss. The report for the Surrey Cryptics shows a losing sequence for our 'leading' skipper of 31 matches, essentially all matches between May 2000 and September 2002.
Although this is statistically improbable, it matches with the data in the system. BUT, the data does not match the source data used to migrate from the old off-line system to the on-line system, where there are several instances of our skipper winning the toss.
Appreciate your views.
Best regards, Peter Andrew (statto, Surrey Cryptics CC).
Hi Peter,
I have moved this to the questions section.
If I have understood correctly, you are saying that when your database was migrated then the toss information didn't come across.
We migrated your database way back in May 2018 (some 4.5 years ago).
(I only wish you had raised this a bit sooner and it may have been easier to fix)
There are two solutions to this:
You go and manually edit the matches and just update the toss information (this just requires you to enter each match details screen, update the toss and then hit save)
We re-migrate your old database (I still have it)
I am not recommending #2 though since it has been so long - and if you have changed player, club, team, grade, ground names then a re-migration will introduce a lot of duplicates which you will then have to clean up.
Let me know what you would like to do
Hi Mark - thanks for the quick response. Yes, it would seem that the migration defaulted to the home side having won the toss, unless there was no toss result recorded, in which case it's (correctly) blank.
Had I known about the data discrepancies, I would have raised the issue earlier. But it's only the release of your new report that has identified the anomalies. I assume you may get a few more similar situations from other early adopters.
I can see why option 2 is undesirable, although I doubt that much of our data has changed.
However, that leaves me needing to reconcile a few hundred matches, and then amending those that are showing wrong data.
I don't have the original source data (i.e. the scorebooks), so it means I would first need to look at every match in the old database, manually note the toss result, and then proceed as you suggest. Unless there's a report in the old system that would show this data?
Otherwise, what would be most helpful would be if you could run a simple list from our old database, showing:
* match date
* teams involved
* toss result (or blank, if not recorded)
.....and mail it to me (Word, Excel, .pdf or any other commonly used format).
Best regards, Peter
What did you want to do? We can start with say 33% of your matches so you can get a feel for what duplicates might arise (if any).
That sounds like a sensible approach, yes let's try that. Thanks.
Hi Peter, I have gone ahead and re-migrated matches from 1990-1992. Have a look at your database and check that it hasn't created duplicate matches and players. If it looks ok, let me know, and I will do the rest.
Just as aside, I had a look at these early matches and their toss info (in the old database) and it seems as though there are plenty of times where the toss info has been left as the default - which is where the 1st batting team wins the toss. I am not sure your original data is that accurate to be honest.
Hi Peter,
Did you want me to continue with the rest of the re-migration?
Mark - our early data is indeed flaky, we are a single team wandering club (we have no ground) playing friendly matches only. Our data is as good as whichever of the team is persuaded to deal with the scorebook on the day.
In many cases, the toss result is unknown, and therefore unrecorded in our base data. Because 'unknown' is an specified option in the on-line system, I expected that these situations would migrate as unknown.
However, you tell me that all these situations are now recorded as 'the 1st batting team wins the toss'.
There is no point in our continuing on this basis, so I will find a way to reconcile the whole list manually. Can you just tell me which match was the last that was migrated from our original database, so I know when to stop?
Regards, Peter
Mark - you are quite correct. I had never noticed the 'unknown' button in the old system, and was unaware of the default setting when no choice was made. Apologies, entirely my fault.
I see no benefit in continuing the re-migration, since it's inaccurate data anyway. Feel free to close this thread, and I'll get on with finding the best approach to reconciling the data.
Regards, Peter