You can use the Separation Model like you referenced. As you noted, you then need to maintain two FileMaker security configurations. So why not use an External Authentication instead such as Active Directory or Open Directory. That way you only have one place to keep the security for both databases. Also, many companies already have an Active Directory going to file sharing or email and it is just a matter of hooking FileMaker security to it. That way a user shares the same User ID and password for not only FileMaker, but their other server services such as File Sharing and email.
Take into account that if you want to use the separation model it will take a lot of scripting to make things work. On the other hand, you'll always need to create calculations and relationships in the data file, specially if you have – and you will have – to use calculations.
After working more than ten years with the separation model I'm done with it. I'm back to the sigle file solution and I'm happier than ever.
I'd suggest you to create a script to import all data from the old version and another script to reset all user passwords to 12345, as I never keep passwords in any field inside my solution.
All my customers know that when we update/upgrade their solution all passwords will be reset to 12345 and then they can change it to whatever they want.
Just my 2¢ of Mexican pesos.
The Separation Model is a good model if you have lots of time (and budget) to handle all of the intricacies. Likewise you should never work on schema of a live production database. Those are all great rules to live by for really large databases where accuracy and stability is more important that rapid application development. Also, those methods usually require much more development time and thereby money.
The reality of most FileMaker solutions is that at most they have a few hundred users and that rapid application development needed to meet changing business needs is more important than the computer science theory on developing databases.
Like Ibrahim, I tried the separation model on some clients willing to pay for it. But most of my clients don't care about database theory and they are interested in getting fast solutions to their business processes for a reasonable price. So it has now been several years since I've done a separation model database for clients. But I always have it as an option and there are situations where it is particularly useful such as a large verticle market solution.
So I concur with Ibrahim's comments but still with a suggestion of using Active Directory. I am really sold on Directory services because as a developer, I pass on the duties of password resetting to whoever runs that Directory service server which most importantly is not me. I rather dislike resetting passwords for clients since that is not a type of work I like to do.
Thank you all, I'm amazed how quick you all are to help and appreciate that.
External Authentication is something I would prefer using and will aim for in future FileMaker solutions and appreciate your input on this. It make sense to have all security handled in one place.
The current solution is sadly specified from the start not to use External Authentication, this due to that the client have FMG and PHP connections from devices not apart of an OD or AD.
I will look in to the possibility to create a script for importing the data. Sadly this solution use FileMakers’ Serial Number function and not Get (UUID) or any other Unique Identifier function for Primary Keys, so might still be a lot of manual alteration needed.
This is however something I will keep in mind if creating a solution from the scratch.
A script to reset the accounts will not help here when we do not have a preset of accounts and maybe 10-20 new accounts can have ben added between updates. This is however a good idea when possible.
Taylor and Ibrahim:
Thanks for the input on Separation Model vs Single File Model. Your input and my own testing make me think that this solution we have is better kept as a Single File. Will take up more time then it is worth to separate it in to two files and most likely cause more problems then it will solve.
Thanks for the link. Will study this thread.
- The current solution is sadly specified from the start not to use External Authentication, this due to that the client have FMG and PHP connections from devices not apart of an OD or AD.
The FileMaker Server makes the connection to AD or OD, not the clients. So even if you're authenticating through a PHP web site, the FileMaker server will do the authenticating to the AD or OD. So you don't have to worry about the end devices not being configured with AD or OD as long as they are able to connecto the FileMaker Server.
Good luck with the Single File Model. In the long run I think it will save you time and trouble. Not that there are not times for the Separation Model, but I avoid it unless there is a specific need for it.
Thanks for pointing this out with AD and OD when using FileMaker.
This will open up more options for the security of the solution, if the customer is willing that is.
And I will stick with a Single File on this solution.
Thanks again for all the help.
I've started to work with RefreshFM from Goya. You clone your development file, grab a copy of the live production file, and RefreshFM automates the rest. Brings all the data from the live file into the development file, resets serial #s, etc. Nicholas Orr at Goya has been most responsive to any inquiries I threw his way.
Interesting, hot topic(s)
Personally I have several solutions built with Separation Model: I must admit I rarely used the "I send you the UI file and you're updated in minutes" option, both because users' reluctance to do even the simpliest operation or (more often) because some changes and the field level were also needed
Despite this if you're in a situation in which you foresee frequent UI changes the SM can be indeed helpful
Also on the plus side of the SM it's the fact that it's fairly easy to separate a file into Data and UI, and that once you've done that you're pretty much done, and all the action takes place in the UI file
The only part in which I had to run scripts in the Data file has been to create/alter users accounts, but it boils down to 3-4 scripts.
Besides you can have a separation model but only keep user accounts in the data file
As far us updating solutions is concerned I tend to work via a remote connection: I'm aware of the risks but in many occasions it's simply not practical or even proposable to do otherwise, expecially when you deal with large solutions and/or solutions in which you cannot afford long down time periods
Take into account that WebDirect doesn't play well with the separation model.
If you have a WD layout in the interface file that accesses data in the data file it will work in FMP but not in WD, unless you set guess access in the data file, which is a huge security hole.
I'd suggest caution if you will use WebDirect.
Hi Ibrahim, nice to hear from you
I haven't still fully explored WD, so thanks for the head up
I'd imagine one would build separate, dedicated layouts in any case when using WD ...
PS: I'm working a separate method to update solutions, or peraphs I should say to update solutions logic
The method was born as the response to the need of creating an XML file for our Public Administration
The problem was
1. to create XML parts only when data was present
2. to run extensive controls on the presence and length of data
3. to run "conditional" controls (If Datum A is present Datum B must be present)
(easy so far)
4. to make the whole thing updatable without interfering with the file structure (field definitions, scripts, layouts etc ...)
The solution was to use ad hoc tables to hold XML skeleton and field names, and a Controls table to hold formulas
Then the developer creates an update "package" wrapping each record and each field in an XML shell, and sends it to the customer where an "unpacking" script extracts field names and content and replaces current records with updated data
The method is "abstract" that is does not rely on any hard coded part, so it might be useful also to update actual data
You wrote: "If you have a WD layout in the interface file that accesses data in the data file it will work in FMP but not in WD, unless you set guess access in the data file, which is a huge security hole."
I've seen just this setup where its a three file solution with one data file and two interface files one WD centric and one FM client specific and it works without guest access in the data file.
Yes if you have the same user name and password in all files, but, if you have a different user name in the UI and the data file then it will require the second user name and password.
In my case, my data file had a special user name so nobody was able to tamper directly with the data file. On login, the UI file runs a script in the data file to set record level access with global fields. This just doesn't work with WD.
When you are specifically designing for separation, password management is an issue (and security in general). You should not leave user names nor passwords in the data file because:
- It's a mess to keep both files in sync, regarding passwords.
- If you store the password in a field it's also a security breach, a big one.
- It opens the door to a malicious user who wants to access the data file directly.
Got it IB thanks for the clarification
Sent from my iPhone