Why does FM asks endusers for UN/PW for External Data Source when there is no 'connection' necessary for the Layout/Scripts/Relationships that they are using?
Sounds like there is a reference to the data from the external source that you haven't identified.
And you still would not get a password dialog unless the user's account/password in the current file do not match that of an account in the file being opened by the external data source.
PS. in FileMaker UserName and AccountName are not the same thing. Your password dialog asks for an account name, not the user name specified in preferences.
I agree, "It Shouldn't"! But it is.
I put in the External Data Source entry on Friday I am the only developer [FullAccess]. I built my three standard DBA layouts: List View, Detail View, and Reports to see the data. I am the only one who can reach my layouts as they are not available in the Layout Menu. Every day since then I've received complaints that the endusers are being asked for UN/PW when they log-in or are moving around the FM solution. This is why I asked the question—it's a puzzle.
You stated: "Sounds like there is a reference to the data from the external source that you haven't identified." Based on what I stated above, where would you suggest I look?
Stuck like Chuck,
Stephen : )
PS: Re: PS. in FileMaker UserName and AccountName are not the same thing. Your password dialog asks for an account name, not the user name specified in preferences.
I know, but the outside world calls it UN/PW; thus, AN/PW might confuse the issue and require additional explanation making the use of the short-hand useless. In addition, since FileMaker's UN can be changed by the enduser at will (IE: "Joe the Janitor" can call himself "Patricia the President") it makes the FileMaker UN kind-a feckless as there is no validation to it at all. (One could literally use the User Name preferences field as the message input to a chat room!) Another one of my '17 reasons' why I shake my fist at FileMaker's programmers.
I would check any script changes that you have made for any incidental references to the external data source. You can enable the script debugger, log in under their account name and password. (I wouldn't use abbreviations like UN for a FileMaker issue BTW--given the potential confusion of AN's vs. UN's.) You can then test to see what is where both in terms of layouts and scripts when the Password Dialog pops up.
Also, is it possible that you had the file down off the server, worked with it, closed the file with one of your layouts up and then put the file back up on the server?
That could trigger a reference to the other file even with a different starting layout specified in Field Options and this is a "gotcha" that has surprised many an experienced developer.
Unfortunately I cannot log-in as the user. I could do an 'over the shoulder' observation.
I work on the production DB, no local-copy issues, but this is good thinking!
"Incidental references" in scripts... that could be a place to go hunt deeper into the wood.
Thanks for your help!
Is the external source a FM file or something else?
FileMaker. : )
That sounds like the behaviour of ESS tables when the ODBC connection is not present / available.
When FM can't find the ODBC connection, it - rather uselessly - asks the user for credentials.
I cannot say why. Maybe it is feeling lonely at the loss of a good connection, and needs to reassure itself there is someone sitting the other side of the user interface.
Bug? Feature? Psychosis?
"I'm loving it!"
So… therapy for the old DB, eh?!
This could get expensive.
Of course you can log in as them. You don't need the same account name and password. Just add a new account with the same privilege set plus your own password and use it to log in and test the system.
Retrieving data ...