will the users have to log in once to open the interface file and a second time when they try to access data from the data file?
If you define the same account names and passwords in both files, this will not be necessary. When something in a FileMaker file references a different Filemaker file that is not currently open for that user, FileMaker first attempts to open this additional file with the same account and password as the current file so you won't get a second password dialog as long as you keep identical account names and passwords in both files.
what is the best way to manage accounts with the separation model?
Any time you have more than one password protected file to your system a set of scripts should be added to your system to manage adding/changing accounts and passwords to ensure that identical accounts and passwords exist in each file to avoid that extra log in dialog.
currently some users can add or delete accounts and change the passwords in the single file solution using a script. if they run this script in the separated solution i assume this will only change the information in the interface file and it will no longer allow a user to access the data file unless the password for that user is updated there too? can the user account information be changed in both files with a single script or do you need to open up the data file itself? i'm confused?
This is the starting point for your scripts for managing account/password changes to your two files. Similar scripts should be included in both files and you run the same scripts in both to update them both in the same exact way. If the user's new password, account and/or privilege set is stored in some global fields, this data can be accessible to scripts in both files so the user can specify the details needed and then run the required scripts. A script in yoru interface file can include a perform script step to perform the account update scripts in the data file. (Perform Script can specify a file in another FileMaker file.)
certain scripts checked to run with full access won't work unless run from the data file...what does that mean exactly?
It means that the script to modify data normally protected by security settings is a script you create in the data file, then you use Perform Script in a script in the interface file to run this script in the data file in order to take advantage of the "run with full access privileges" setting to do things normally prohibited by the user's privilege set.
ahhh... ok... i think i understand most of that... but just to be sure with regard to the full access question... do you mean that as long as the launching script in interface is set to run with full access any script it calls (either in the interface or in the data file) via perform script will run with full access also, or do you need to check full access in all the scripts and sub-scripts for this to work? conversely, in the inteface file if the only step in that script is to perform the script that potentially has a privilege conflict in the data file (or the interface file i suppose), can you leave full access unchecked in the launching script as long as it is checked in the potentially conflicting script?
is the fact that a full access script won't work unless it is run from the data file a filemaker shortcoming/glitch/bug, or is there a reason or advantage to require it to be run from the data file as opposed to running from the interface file? thanks again!
The option should be specified for each sub script where security privileges might keep it from working correctly.
conversely, no you do not need the calling script to have this setting specified if all it does is call the script in the other file.
It's not a bug, it's behavior that's documented in FileMaker help.
got it... thanks phil... i really appreciate the advice and information... but i still wish i could just leave all my scripts in the interface (my brain is already overheating with the rest of it)... maybe that will be another checkbox in 12 ;-)
phil, i just wanted to say thank you again.... i successfully made the transition using your instructions (although it was a tedious process with a few hundred to's) and actually your comments about runnig certain scripts from within the data file helped me fix something else completely different. i had implemented drag and drop functionality in the previous (non-separated) solution but this technique relied on global variables generated in the data file and not visile to the interface. but i remembered your comments and tried runing the slightly modified script from within the data file and it works! you saved me a lot (and i mean a LOT) of head scratching to figure out why it broke and how to restore it (the drag and drop feature). much appreciated!!!
I didnt get it to work. I followed the above separation model and test it by writing a script in interface, which delete user account, delete user record in user table i created and also called a script in data to delete user account.
Somehow, it manage to delete the user account in interface and the user record in the user table but NOT the user account in data. To play safe, I even set "run with full access privileges" in both interface and data scripts.
Can someone advise? Thanks.
i don't know if this will help, but during my transition, i vaguely remember hitting a couple snags with deleting user accounts. i did not have a test to make sure that i wasn't deleting the active user account and this created some strange behavior when i did so without realising it. i would check to make sure that you are not deleting the active account. and the second thing i changed, was to delete the data account first, and then the equivalent interface account. also, it is a little unclear from your post, but is your user accounts table in your interface file? i have mine, along with the rest of the data in the data file and everything seems to be working fine now... hopefully one of those things will be the fix because that is the extent of my knowledge on the subject. if not, phil will know much more than i about how to proceed... good luck!
yes, i also tried yr method of deleting the user in data account first, then interface account, and finally the user in the user table in data. But it still didnt work. Somehow, it just wouldnt delete the user in data account. ;(
Yes, i will want all in interface to reference/access data (no data in interface).
i certainly hope phil or someone who can come to my rescue.
are you getting any dialogs, or does it appear that the script ran properly? have you tried running it with the script debugger and the data viewer to make sure that the parameter (the user account name) is being passed correctly to the script in the data file? are you passing the field from the user accounts table, or the account name in quotation marks? you could test by hard coding in an account name and eeing if the data script will delete that hard coded account name... will keep thinking and let you know if anything else occurs to me... sorry!!!
Oh.. i'm using Set Variable to pass the user name to $$UserName. And then thinking that it would pass the name over to the Data scripts.. but i listened to you and create a dialog box and to my surprise it didnt manage to pass the $$UserName over to Data! Why? Thought $$ is global?
How did you pass the username over to data for the script to delete account?
"If the user's new password, account and/or privilege set is stored in some global fields, this data can be accessible to scripts in both files so the user can specify the details needed and then run the required scripts."
It seemed like somehow i couldnt store the username in global variable and pass it over.. Does global fields mean a table to keep the temporary username info?
A global field is different from a global variable. A global field is a field defined in a table, but with global storage specified.
Global Variables are specific to a file. You cannot access a Global Variable in File 1 from File 2 which is why I specified a global FIELD instead of a variable. It's also possible to pass data from one file to another in a script parameter, but since the user needes to type in their new password and/or account name anyway, it makes sense to use fields with global storage for these fields so that the data in them is accessible from both files.
Yes, i finally found the problem! After i change to using global field instead of global variable, it worked!! I created a field name PassUserName and set as text and global storage and everything works smoothly.
So, lesson learned here is that global variable is not able to pass value over from interface to data. ;(
And the only way now is thru global field. I wonder if there are other ways..
Thanks johnhorner for your help.. it makes me think so hard that the solutions surfaced!! ; )
I wonder if there are other ways..
If you read my last post again, I mentioned an alternative way to pass data from one file to another...