We have a tournament scheduled for May 2nd. One of player renewed membershp two days ago, and showed me a photo of “Expiration April 30, 2026” on her login page. But on her MSA page, it says " Expiration Dt. 2025-04-30" and “Last Change Dt. 2025-04-12”. And SwissSys pulls 2025-04-30 as well for her expiration date. What could be the issue?
Could be a synchronization issue.
To ease your mind you could create a test tournament with the player to submit and test the validation to see if it accepts the 2026 date. Just be sure to delete the test without actually rating it.
Without the ID, there’s no way to check on this.
Please help me check 31856562. Thank you very much, Michael.
The ‘new’ player lookup page: | US Chess.org, shows his expiration as 4/30/2026. Looks like the update to MSA got lost somehow. I’ve alerted the membership department, they should be able to force an MSA refresh for this ID.
They’re already updated on MSA.
Also “her expiration”.
1 Like
I have a similar issue with an entry,
https://www.uschess.org/msa/MbrDtlMain.php?32569373 says “This is a non-member record”,
but | US Chess.org has
| Membership Expires |
|---|
| 09/30/2027 |
It has been synced so it now shows as a current member on MSA.
When we transition to Leago, the process for updating the member pages (which will be on the Leago system) will change, but out-of-sync errors can happen any time you have two separate databases, so we may need a similar mechanism for forcing a sync.
Thank you very much!
another case:
https://www.uschess.org/msa/MbrDtlMain.php?32593254 “This is a non-member record”
but but https://new.uschess.org/civicrm/player-search has
| Membership Expires |
|---|
| 09/30/2026 |
Please help sync database
These out-of-sync look fairly common?
Thank you. It looks sync’ed.
Also looks like, the rating changes resulted from Is there a bulk rerate happening after Sep 17, 2025? have been undone.
Thank you very much.
We discovered a strange error in the rerate from a week ago, it was computing the wrong estimated ratings for new players where that estimate was based on birthdate. For some reason it was not finding a birthdate for players for events from late 2023 and early 2024, so it was using 1300 or 750.
I think that’s because that rerate ran longer than expected and it was running against the overnight jobs and backups. We normally don’t run rerates then because it slows everything down too much, apparently there are other problems with that as well.
We fixed the problem and rerated those months this week, so that changed a lot of ratings, mostly back to where they were two weeks ago. Makes me glad we’re nearing the end of rating events on this software, it’s starting to show signs of old age.