dajoker wrote:My current suspicion is that there is some kind of file outside of that <unisNumber> directory which enables finance. I'll post when I find it.
If I was the designer, I'd have a hidden "last sync" value stashed away somewhere. If the last sync in the data file matched my hidden copy - all is well. If not, then I know I have some fixing to do and it's best to lock the finances until MLS is in sync with CHQ.
If I'm right, and you do find it, it would probably NOT be a good idea to post the details. Circumventing it could be a violation of the CoC (forum rules).
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.
So we can better help you, please edit your Profile to include your general location.
Well, this doesn't exactly provide a way to twiddle the bits and cause an unlock of finance, but it's how I fixed it for me.
The reason for the lockout , I think, is because I first restored my pre-upgrade backup to my new 3.5.0 install. My theory is that MLS knew it was an older database version (because database versions are stored in the backup) and then went ahead and did its conversion, and prompted for the Send/Receive to get the "file" from Church headquarters. Subsequent restores weren't enough to change that, but my restore on the main computer (with a current backup from after the "file" came down) didn't prompt, so it would seem somehow that the restore doesn't change that attribute but if you clean it out and start over (with a valid, non-prompting backup) fixes the problem.
I fixed it by deleting the <unitNumber> directory (again, as covered in the backup/restore procedure wiki) and then restoring the current backup. All is well now. If anybody can share why the restore initially failed on the main computer (causing a failure to do anything else ever again) I'd be interested in hearing about that. I did not try restoring a second time to cause the problem, but I can if that would help. If a developer wants to try reproducing it I can share the backup or unit number; e-mail me directly.
I'm still baffled by this. In our ward, we have one computer. If we get a new one, the stake takes the old one away. We still have ONE computer. I've never received instructions about how to manage a second computer "to check our backups" and wonder how many units do this (and why).
"Updated the restore from backups and synchronizing financial information process: If the MLS database is restored from a backup, MLS will now compare donation and expense information in the backup file with financial information sent from Church headquarters or the assigned administrative office to ensure both are the same."
rpyne wrote:Quote from the MLS 3.5 Release Notification:
Assuming this is directed at the original question... yes, that's in the readme. No, apparently that isn't related. See my next-most-recent post in this thread for why.
One more odd data point. Today I received another upgrade (3.5.0_21059) on the main machine. All is well, nothing to report.
Thinking I was oh-so-clever I downloaded the same version which was, just today, posted to the MLS download site and put it on my backup-testing machine. Smooth as silk, logged in and all was well. I had not, hitherto, restored a backup from today, so the version of the database at that time was still the version from the previous beta build (3.5.0_21021). I then restored the backup from my post-upgraded main machine and during this time I received a prompt which I foolishly did not write down, but which seemed to say that I would lose things and finance would be locked until a sync. From this point on finance was locked out on the backup machine.
Two things:
1. Deleting the unit from MLS and restoring from the backup fixed the problem of being locked out of finance.
2. I can't figure out what kind of magic must be involved to allow a never-synchronizing system to know that its brand new, backed-up five minutes before version of the MLS database, is outdated and that a send/receive is necessary in order to proceed. The comment from MLS is totally wrong... nothing on the backup system was within three days of current, and everything on the primary system was brand new including newly-issued checks, a send/receive for that, an upgrade of MLS, a backup, and then another send/receive and another backup (overwriting the first). It was this MLS database backup which the backup system received, so nothing about this could possibly be older than the backup MLS's environment.
Anyway, I think that's a bug, and while it may only happen during these upgrades (so nobody else will see it since nobody else obsessively tests backups) it's still something that may hit somebody in the future. Possible reproduction steps:
1. Have MLS 3.5.0_21021 (or earlier) installed on two systems. One system does all of the synchronizing, the other can effectively have no connection to the Internet other than to manually download new versions of MLS. Implied in this... have the same unit on both systems.
2. Let the auto-update, or maybe even a manual update, of the primary system take place. Once done and confirmed to work, backup the database.
3. Restore that database on the backup system after upgrading MLS on the backup system manually (because it never synchronizes so it can never get the auto-update stuff). I think one important point may be to upgrade the backup system's MLS, and thus its unit's database, AFTER the backup is taken from the primary system. It may also be important to have time synchronized properly between the two systems (implement NTP, or whatever windows' version of NTP is if stuck on windows).
My wild theory is that the detection of "older database" vs. "newer database" has to do with the backup time, not necessarily the age of the data within the backup. This just came to me while writing this so that hopefully explains my different opinion from the top of this post to here. If correct then time synchronization really matters to reproduce, as does the time of the main system's backup vs. the time of the other database's conversion. It also means that the detection of the detection of which database (currently used, or about-to-be-restored) is most-current is a little simplistic. If my theory is correct then an old database could be restored over a newer one by simply getting a more-recent backup of the outdated data than the more-current system has. If the newer system was converted five minutes ago, take a backup right now and it will be accepted.
If my theory is wrong, of course, maybe this data point will help others find the real logic behind the need to synchronize w/Church HQ.
AB
I also keep a spare box, not to test backups, but to load backups from our far away units (some up to 12 hours away) so I can assist the unit clerk by seeing the same thing that he is seeing in his MLS database. Since the upgrade to MLS 3.5 I can no longer do this because I get the same message requiring a finance file download from CHQ. So far I've hit the same wall when I load the unit's backup on the primary (stake) computer.
I'll try the "deletion/restore" trick to see if that will let me see the finance data. Hopefully that will solve the problem, otherwise my ability to support our unit clerks will be seriously impaired.
Success! I just went over to the stake center, made sure that one of our wards had the most recent build of MLS and took a backup. Then walked down to the stake office, deleted then added the ward to the stake computer and restored the data from backup. Worked like a charm so the deletion/restore seems to solve the problem of being locked out of finance.
Thanks very much, dajoker!! You saved me a lot of grief with this hint.
