This should not happen. When accounts with identical account names and passwords are defined in two files, references to the second file from the first should automatically open the second file with the same account name and password.
Though I would set the interface file to auto-enter the same account name and password for each user and leave the separate accounts only set up in the data file. That then should trigger a single log in password the first time something in the Interface file refers to the data file and thus tries to open that file. That way, you do not have to created and maintain identical account names and passwords.
I already thought that this should not happen, it just happend this morning. Until yesterday I did not have that problem at all. So something happened or something went wrong,
But, if I use your idea of a "single log in" in the interface file, how do I handle the lay out security? The different users get access to different lay outs. With other words, the lay out security is handled in the Interface file, and the record security is handled in the database file.
Make sure that account names and passwords are exactly the same. (passwords are case sensitive.)
Make sure that your files are not damaged in some way by using Recover to run a check on them.
how do I handle the lay out security? The different users get access to different lay outs.
In that case, you may need the duplicate accounts and passwords, but as we have discussed in other threads, you might also design your interface file in such a manner that users simply can't select a layout for which you don't want them to access.
Perhaps I misunderstood what you mean. Yes, the lay out security is done the way in your post. (Not in security). Users just don't have access to certain lay outs, but that is based on the account name on login. That is why I need to know what kind of user I am dealing with in the Interface. (It already starts with the "start up" lay out). And if I have a general login for everyone, they all get the same lay outs.
I use the "account name" of filemaker and not the "user name" of the system, because there are so many changes in students, so the students all use the samen login, as well as the teachers.
Or do you mean a general login in which I activate the Interface file and the data file, and once they are open use "activate account"?
Sorry for talking so much of your time,
Thank you for the clarification and that's a point that I hadn't considered. But you can define an unstored calculation field in the data file that uses Get ( AccountName ) to return the current user's account name in that file. A script in the interface file can copy that value into a global variable or global field on startup in order to have a simple way to identify the current user's account name.
O.K. Phil, this looks very good.
So, I start the interface file without an account name and password, and the interface file opens the data file. The data file will ask for an account name and a password, and I put the account name in a unstored calculated field.
And in the Interface file I collect the Account name in a script and go on in the Interface file with the account name of a global field. (Coming from the data file)
But, at what moment is the Data file opened? Is that directly on start up of the Interface file? Or at the moment the Interface file ask for data from the data file?
Sorry for taking so much of your time, but I want to understand how the connection between to files is working.
PS. Was a corrupt file, that causes the lost of account name and password.
Unless you have a start up script in the interface file that explicitly uses Open File to open the data file, the file will open with the first event in the interface file that refers to data from the data file. That means that a script that has a step that refers to this calculation field in the Data file should be enough all by itself to open the file the first time that it is run.
But please note that I am providing "theory" here, not from actual experience. Test things and see how they work for you.
Thanks for your effort and time Phil,
You helped me out again. I have been experimenting with this issue, and it works fine the way you suggested. I just wanted to understand the way the connection is working better, so I can deal with this issue in a better way in other cases. I don't want to type over your suggestions, I always try to understand what is happening in the system.
Thanks again Phil,