- When a user logs in, they have to enter both an account name and a password. If they come to your machine and try to log in, they will need to change the default account name to that which you assigned to their account and then enter their password. If you did not edit their account after converting the file, their password was used for both the account name and the password in the file created by this conversion process. You will want to change their account name to something else so that they are not entering their password "in the clear" as the account name.
- Passwords in the old file are not case sensitive. They are case sensitive in the converted file. So if the password is XYZ in the original file, xyz would open the file in the old version, but it will fail in the new.
- For some odd reason, the user name specified in preferences is put into the account name box in the password dialog as the default account name. If this user name is not the same as the user's account name, they have to clear the default account name and enter their own account name before then entering their password. This causes a fair amount of confusion amongst new and even more experienced developers.
I'm not sure I follow -- these users all had account names and passwords and used them to log in before the upgrade (in fact, they are still using them on the old version). For example, if user abc had the password test1234 before the conversion, what would their login info be for the new version?
Regardless, why can't I just delete and re-add account abc, set their password, and have the script work like it does for when I add new users?
Sorry, I was thinking of even older versions of FileMaker that did not have accounts, only passwords. Please disregard that info. The info about account and user names does apply however.
You should be able to do exactly what you describe.
Which do you want to have happen?
The user runs the local file's script and the password protected file on the server opens without any other dialogs.
The user runs the local file's script, a password dialog appears and they fill in user name and password.
For the first to happen, the account name and password used to open the local file has to match to the account name and password of the file that is being opened on the server.
This one just bit me. Check the File menu => Sharing to see the settings. If it's limited in any way then those people cannot login. I did NOT expect something that worked very well as .fp7 to fail so miserable after conversion for FM15, but it did. Even my developer (full access) would not login until we reset the Sharing (with the files off the server).
Something to consider,
Which Settings do you mean? When I go to File->Sharing->, I see "Upload...", "Share...", "Enable...", and "Configure..."
@philmodjunk, either scenario would be fine at this point, but neither seems to be working.
What settings do you see for the files? You may need to look at the settings as they were before conversion to give you the clues.
Is there any chance the you have external authentication going on here with AD/OD?
Some screen shots of Manage | Security might be enlightening. Both of the file that has the script and the file that it opens.
Since the upgrade has to happen today, the client confirmed that it's acceptable to just add new account names for everyone (e.g. "abc" might become "abc1") so that they can log in and use the new version. Since this will (hopefully) only be an interim fix, I will revisit this tomorrow and help you all get a deeper look into what's going on.