Option 1: Set up all files with identical account names and passwords. WHen you open any file with that account name and password, any references to the other files will open them with the same account name and password automatically. As far as I know using Open Directory and External Authentication won't change that.
Option 2: In some cases, if all or most users need the same level of access, you can use File Options to open that file automatically with a specified account name and password. This means all users have the file open with the same account name, so some scripts/calculations that refer to get ( accountName) may not be something you can use in such a situation.
In cases where you need to open the file with a different access level, you can hold down the shift (windows) or option ( mac) key down while opening the file. You can also perform a script in this file from other files that uses the Relog-in script step to open the file with a different account and password.
Hey Mr Junk,
Oh, how I wished and hoped option 1 would work. The way I understand it is to validate OD credentials the FM file must be located on the server. The way our's is set up though is that the client has the main database on their computer. The two external datasources are located on the server though. I attempted to test this and when adding the OD group to my client file, it doesn't work properly. Gives message that the user could not access the file. I did create a local user on all the external data sources and it did work like you described. Is there a way around this?
Option 2 unfortunately would not work either. There are 4 different security privilege sets. There isn't one that is used and a lot of error reports/tracking uses the signed in user's name to verify no one is editing data.
I'd put that "main file" on the server as well. I don't really see the reason for keeping the main file "local".
And there are still ways to get option 2 to work. Note what I posted previously about scripts that use "re-login" to open a database.
Yeah. The main file being local was a design decision on the initial creation. I believe the reasoning was that it would perform more efficiently due to the amount of users accessing as well as the server being offsite. Unfortunately, this cannot be changed at the moment.
For option 2, unfortunately re-login looks like it only applies to the local user. There's not an option to relogin to a remote server. I'm going to stick with the dual login for now. Thanks for the help, though. As always, much appreciated.
That is not a problem.
In the local file, you use perform script to perform a script in the remote file. You can pass data, such as an account name as a script parameter to the script in the remote file. The script in the remote file uses Re-log in to re-log the user into the remote file. SInce the file has to first be open before a script can be run on it, you set up the remote file to auto-enter an account name and password with just enough access to permit the local file to perform a script on it to re-login under higher access.
Awesome idea. Didn't think about that. Long day. I think I'll look into this on my next revision in a month or two. Again, you're awesome. Thanks again.