Hi, having full access alone is not enough, you need to allow access through Manage,Security,File Access. I think it was intorduced in Filemaker 11.
Thanks for the response
That's correct you do need to allow access. As I have FullAccess to all the files, I have done this - both manually through the menu options you mention above, but also by authorizing through the dialog that pops up when the new file connects to the existing...
Thank you so much for the response and the reference doc.
I shall persevere!
I'm running into a similar problem today, only with scripts instead of tables, and I'm not using Go for this application. Alas, FileMaker's help documentation on securing file access wasn't any help to me.
I have a a script that calls scripts in other files. When I set it up the first time, the script references all work fine. After I close the files, re-open, and run that script again, some of the references to scripts in the other files are broken, but not all. (All files require authorization for access, and all files have that authorization in place for the file containing the master script.) The Perform Script  steps triggered error 100 (File is missing), and if I tried an Open File  step first, I got error 825 (File is not authorized to reference the protected file).
To get something done, I temporarily turned the authorization off in each file. I did not deauthorize any files in the process. When I turned the authorization requirement back on, FileMaker prompted me to authorize each of the files that had been authorized before, then told me that those files were already authorized (Duh!) — but only the files that broke their references from the master did that. It's behaving as if those files corrupt the file authorizations when they close.
You are right... Filemaker Go is a red herring. I've just done some testing on my desktop and I have the same issue.
Sometimes the authorize file dialog only pops up when you go into Scripts or Manage > Database...
I tried running a recover on all files involved just to see what would happen. The Recover.log file didn't show anything noteworthy, and the recovered files had the same behavior.
+ 1 - In a multi-file solution converted from 11. The original files have all of their authorisations in tact, but two files added subsequently don't seem to honour authorizations in either direction. TO's drop their links, scripts don't show up properly ... the only way around it seemingly is to turn the file security off in these new files.
... or change the name of the file in External Data Sources by adding or removing the file extension. This seems to force re-autohrisation, but only seems to last for the duration of the current session.
Don't know if you've already come to some resolution on this, but I, too, was running into problems with files not respecting the authorizations I set up in the File Access tab of the security dialog. Perhaps your problem was similar to mine: namely, any file that is a copy of another file may not have its file access authorizations respected. Apparently, there is no fix for this. After some back and forth with FMI tech support, here is the scoop:
The problem manifests itself only when you use a copy of an existing database file, regardless of how you generate the copy (e.g., manually copying a file, using Save As, etc.). The underlying issue is with the "universal file identifier" embedded in the database file, which gets duplicated when you copy a file (rather than, say, generating a new UUID), and is apparently referenced in the authorization token.
No info on whether this bug will be addressed in future versions of FileMaker.
I've been trying to consistently replicate the issue. I have been able to resolve it, but here's what I had to do:
- Go back to my file template in 11.
- Save a Compressed Copy.
- Convert the template to 12.
- Manually rebuild the contents of the file.
- Give the file a different name.
- Change the External Data Source references in the main file.
So far so good, but I have to continue to test. This process has broken all the links to scripts :-/
I suspect that the issue is in the conversion, and that FileMaker 12 is not handling the moving over of some aspects of the Authorisation infrastructure properly during this process.
I can't replicate the UID issue on duplication that you posit. If that were true, that would be a serious flaw as it would prevent developers using template files (encouraged as good working practice) in any solution that requires authorisation.
I'll post back if I am able to get any further with this.
The issue I was having is reproducible, and is unrelated to FM11 conversions (although I believe the bug exists in FM11 as well as FM12). Here is how to reproduce the problem:
- Create 4 files
- FileA_new (a brand new file)
- FileB_new (a brand new file)
- FileC_copyOfB (a copy)
- FileD_copyOfC (a copy)
- In FileA, authorize FileB to access FileA, click OK.
- In FileA, then try to authorize FileC or FileD ... it won't allow you (see screen shot below)
You'll also notice that if you were to create a simple script in FileA (just a "Show Dialog" step), and try calling that script from the other files, say FileC, you'll notice that you are asked to authorize access to FileA ... when you do, it automatically removes the authorization for FileB. Between FileB, FileC, and FileD, each time you open the files and try to authorize one of them to access FileA, it removes the authorization for the other files.
Sample files are attached, below. I do agree with you that this is a pretty significant bug with the feature.
- Create 4 files
2 of 2 people found this helpful
It has been a while since this thread has been updated, but I came across it while troubleshooting a similar problem in my own multi-file solution. It seems in FileMaker 13 you can now reset the file's unique identifier using the "Reset All" button under the "File Access" tab of Manage > Security. This is particularly useful in the event of using a template file, or when creating new interface files from existing ones (i.e. copying a file retains the file's unique identifier).
I thought I'd mention this as I couldn't find it earlier in the forum. I was initially thinking it would be better for the process of resetting the file's unique ID to be automated... but this is probably not ideal for vertical solutions, and for the purpose of ensuring authorisation isn't broken when restoring from backups etc. However, perhaps it could be handy if "Reset All" could be scripted??
I am just experiencing this issue in FMP15v1 - I removed all authorized files from the server file and re-authorized it.
Now it fails to work if regular users (non full access) try to connect and I get Error 825 on first attempt then just Error 100.
I repeatedly de-authorized then manually authorized the file again without success.