1 of 1 people found this helpful
Add the same login to the data file (guest?) AND (this is important!) the same account in the data file should have NO privileges.
But it sounds like you are using the "form" in the interface file to re-login. If these are accounts in both files, perform a re-login to the data file first and then to the interface file.
File References may be triggered even if you don't have any other fields or tables or anything that you think is going to open the data file once the interface file is open.
I still find it really strange that I never had this login problem with the exact same solution in FM 11. I liked this logic, as I could avoid having a script in the data file to re-login.
I'm curious, what does actually trigger a login on the referenced files?
Message was edited by: Thomas Staehli I have the same kind of login script on an old Filemaker solution with more than 60 files on FM11, with one file used for main login. Never had this issue... Not to mention if one day we convert the files to 12, I would really hate having to activate the guest account on 60 files and script a relogin in all those files just to make sure no random file would ask for a login first with no good apparent reason...
You may be triggering it simply by what is the initial screen, which can be either:
- the last screen used when it closed in an unserved environment (which could have changed after conversion if you used the file of-line), or
- the screen it is set to go to on first window open (set by either a startup script or go to layout on open (converted to a trigger on first window opening)
If either of these or any layout it lands on before getting there references an external table in the data file, or is based on a Table in that file (even via a TO in the local file), that could now be attempting to read from the other file even if there are no elements from that table on the layout.
Some of these behaviors have changed from File Settings to On Opening First Window triggers in FM 12. It is also possible that during conversion, the default layout on which you closed the file was different than where you wanted to open it. Either layout can trigger this.
I checked all the different points you mention but I couldn't find anything that would explain the behaviour:
- The exit script ( OnLastWindowClose in FM 12) goes to the Login layout and empties the username and password and a few other global fields (which are in a parameter table in the interface file)
- on open, the file is setup to go to the login layout.
- startup script (OnFirstWindowOpen), just hides the status bar, resizes the window and sets the username and password fields with "Enter username..." and "Enter password"
I was really careful when I made this, to make sure that nothing from the data file was required (on a layout, in a script, in a calculation) before the user actually presses the login button on the first layout. And it worked perfectly in 11, and still worked fine in 12 until one day it decided to ask me for the data file user name and password.
And as I said, without modifying anything in the file, I cloned it, and the clone works fine again...
I've been trying to reproduce the but with 2 test files, bug so far, I couldn't...
I've made a few more tests. On a dupplicate version, I deleted all the scripts, all the fields in the parameter table, all the layouts exept a completely blank one (and I setup the file to switch on the blank layout), I removed the startup and exit scripts. The files logs in automatically as guest.
Even after all this, when I open the file, it asks first the username and password of the referenced file before it even shows the blank layout... and I again, if I save the file as clone, and open the clone, it goes straight to the blank layout without asking anything...
Is the base table of the login layout a table which resides in the local file or in the data file? And are the login fields on that layout in table(s) which reside in the local file or the data file? (I know the TOs are local, but am concerned with the actual file location of the table's definition in the file system.)
- If both reside in the local file, they should not trigger the opening of the data file.
- However, if either the layout base table or the login fields on the layout actually resides in the data file, that will force it open.
The fact that it sometimes works as intended suggests there is something else going on, but doesn't give much of a clue.
Can you post sample files for troubleshooting?
The layout is based on the parameter table that resides in the local file, and the username and password fields are both from that parameter table.
Saying that it works sometimes is not true. It works all the time until something happens (that's what I want to figure out), and then it NEVER works anymore except by:
- Removing all the relationships and recreate them (or dupplicate before removing)
- clone the interface file and open the clone
You can try it out with the attached files. This is an almost empty copy of the original file, with only a login page. Use the following account (which has full access)
FM12_Login.zip 371.5 K
Your issue is intriguing. I think it may have something to do with having a record or never having any records.
A clone has zero records. When the interface file is cloned, it does not contain any record to establish a link to the data file; thus when it opens, it does not call the data file.
If the interface file has a record, then --- somewhere --- there is recorded a relationship from the interface file to the data file through the LOGIN_LoginParameters --< LOGIN_Users relationship.
It appears there are two or three situations that open the link from the cloned interface file to data :
1] open define relationships
2] open value lists [there are many missing tables, but perhaps some once used a *data* relationship]
3] open external sources
Some other observations:
A copy of your original interface file retains the hidden link to the data file and requests it as soon as the interface copy is open.
A clone of your original interface file does not contain the hidden link. The link only establishes itself once either 1, 2, or 3 above is performed.
Your original interface file had a single record for the Parameters table. This appears to have been used as a filter or find at some point -- based upon the data entered in the fields. I deleted the record in the original, closed and reopened it, but the original still retains its hidden link to the data file which must be satisfied before interface will open.
You wrote in a post above:
[- startup script (OnFirstWindowOpen), just hides the status bar, resizes the window and sets the username and password fields with "Enter username..." and "Enter password"]
It does not set the username and password fields with the entries you describe. The script checks to see if these are the entries, but nothing sets these values that I can find.
You refer to the table used for the login layout as the Parameters table, but it is actually the LoginParameters table. The Parameters table is the one that appears to be used for search criteria.
Finally, I tried to get several clones to replicate the behavior of the original file, but I could find nothing that triggered opening the data file before opening the interface.
No answers for you, but perhaps my observations will trigger some thoughts for you. I would just go with a clone of the interface file. Since all the fields are globals, I see no reason to have a record in any of the tables and perhaps that would keep the issue from re-occurring.
Thanks for taking the time to look at this.
Yeah the example files are not exactly the same as what I described at the beginning, that's why you might find some missing stuff. I actually removed almost everything from the file (forgot the value lists).
I had a lot more relationships, and I noticed that I could remove all of them except for the "ADM - Admission" block, that's why it's still there. If you remove that admission block, the problem goes away ( even if you just dupplicate the admission part and remove the original).
I actually went with the clone file and it worked fine, until it happened again 2 days later...
This is really strange, I guess FM12 keeps track of something and tries to access the external source when it opens.... I just hope that this behaviour won't happen once hosted on FM server....
I think Michele hit the mark. As predicted, your login screen use a local TO directly related to a TO in the data file itself.
If you were to have another example of the same local table which was not related to the data file and use it as the Base Table for the login screen, I think this issue would go away.
I did try what you're suggesting, but it doesn't change anything. Even if the login layout base TO isn't related to anything it will still ask for username and password of the data file.
Okay, I found what seemed to be the source of the problem, but I still don't know why. You can try it with the example file I posted previously it works every single time.
In the relationship graph of the interface file, remove the TO named "ADM_Addresses_Current". Quit Filemaker and re-open the interface file...
Is there a calc field in the ADM base table that references somethiing in the data file? I had the same behavior happen in a fp7 file I developed/maintained a few years back, and Beverly's 4/19 reply is the solution that worked for me. I think in general it's the correct approach because you can never be sure someone who inherits your solution will remember to omit any objects that reference remote data on that first layout, and you also can't predict when FMI may need to change the way FMP will build file references when it first opens a database. HTH.
Everything in the "ADM" section of the relationship graph comes from the data file. But, on the Login layout, there's absolutely nothing. I know because I recreated it. It's a simple layout based on a TO from a table from the local file with 2 fields from that table.
There's nothing that would link the login layout (or the logout layout for that matter) to the TOs from the ADM part and definitely not the TO that seemed to be the source of the problem...
Anyway, if it happens again, I'll definitely go for Beverly's solution...