I sympathise with your intentions in creating global fileds in your preferences table, but because of the different ways that globals behave and retain their values (or not) between single-user and hosted files I stopped using that method. I now create a Preferences Table as you have and only use conventional fields in it, with all other tables' access to the Preferences table via a Cartesian relationship (or Constant = Constant). Through the security control I limit it to only ever having one record (same effect as global values).
I'm not sure I know what you mean exactly "Through the security control ..." Do you mean limiting record access?
I thought I would be safe doing it with a global table, because I only have a single-user application. However, I'm finding that my program won't import a global table (of 1 record) from a copy of itself.
I set up in Filemaker's Security that no-one can create records in that Preferences file.
When you set up and enter data in a global field in single user mode it is stored, I believe, so it should work the way you want it to in this case.
I know it will be no consolation to you, but I set up a test file with 1 Global field, created 4 records, saved a copy, deleted all records in the copy, imported from the original file, and it... all worked perfectly.
One of the favourite ways for an import not to work is that you have a Validation on one of the imported fields, and the data to be imported fails the validation.
OK, I understand what you are doing now. Perhaps I'll implement that in the next version.
I certainly will take your suggestions under advisement. They make sense.
I find that I can import values from global fields just fine. The only thing that I've had to do to make this happen is make sure that at least one record exists in the source file.