- Is it possible that editing access privs in a file in the middle of a backup could result in corruption?
Yes, it's possible. I don't know that any specific causes of this problem have ever been documented officially by FMI, but anything happening at the schema-level of a file during a backup is risky.
The fact that your problem surfaces in exactly those files where the accounts were modified strongly points to a common problem based on that modification. Do you have any way to track when you added the account compared to backup run periods?
We have our backups set to run less often than hourly due to file-size after 10 years in use. I try to check backup times before touching the files for anything which requires a "Full Access" account to perform, just to be on the safeside. Sometimes, I forget, and count my lucky stars that nothing went wrong -- it just takes longer than expected in most cases. However, Accounts and File-, Table-, and Field-definitions are well worth avoiding during backup periods.
Hi, Stephen; thanks for the info. I don't have any record of exactly when I added the account to those files, but if it's possible/likely that that's the culprit, I'll certainly make a point of turning off the hourly backup schedule during any substantial dev work (or at least checking the admin console to make sure backups aren't running at that particular moment). That was an unpleasant lesson to learn the hard way.
1 of 1 people found this helpful
There have been reports that changing account parameters while users are in the hosted file can result in account corruption. I make sure no one is in the file apart from myself if I need to add or change accounts.
Beatrice Beaubien, PhD
i2eye, Toronto, Canada
FileMaker Business Alliance
FileMaker 11 Certified Developer
That would be difficult for me - I regularly have to add/edit user accounts on the fly, and I'm generally not in a position to boot eveyone out to do it. Still, in cases where I have advance notice of new employees, etc., I can add them in off-peak usage hours. Every bit of caution helps, and it's never occurred to me that having users logged into the hosted file might present problems, so thanks for that tip.
1 of 1 people found this helpful
Hi again Ian,
I use a scripted Account creation process so that I am not opening the Manage Security accounts screens to create new accounts, just running the script(s). This has never caused any problems for our system with dozens of users logged in all the time.
Where things can get real hinky is if you edit the account of someone who is already logged in to part of the file system, and bang!, their permissions change while they are using them. Haven't see that crash it, but it can sure confuse a user to have things say they can't log in to a file they they thought they had access to. I always make sure any specific user is out of the system before messing with their existing account.
Move to scripted accounts management and minimize the number of times you need to open Manage Security as far as possible.
Thanks - I've never used scripted account management, but if that'll keep the auth table from getting borked, I'm all for it.
Considering how many people use Filemaker for crucial business stuff, it seems awfully fragile.