One idea has been around since FM7 -- the Separation Model.
If you use a separate file for the user interface, any change you make which does not require data structure changes to the deployed by issuing only a new interface file to drop into the folder, leaving the users' data files intact.
There is a White Paper on the Separation Model available from FileMaker.
Data separation model. Separate your data file from the user interface
file. That will allow you to update the user functionality and leave the
data intact. If you modify the data file you will need to provide some
Direct/FaceTime/Text - 781.223.8884
Thank you, Stephen and Pete, for your answers.
We've been researching the separation model and believe it will work for our case. We would love to get more feedback from folks who work with separation model before.
We have a database which volunteers can signup for an account so they can volunteer at our schools. Once the volunteer signup for an account, this will go through an approval process that involves ID and background check. Once approved, the volunteer can login and tracking the volunteering hours. For the future release, we hope to be able to track this piece of information from year to year.
As we research, we ran across posts mention about user login. Besides from that, anyone have experience/issue implementing separation model on a database that will create user account, allow user login, track historical records, and search large collection of data with multiple conditions.
Advice is greatly appreciated.
What version of FM are you using? Is the solution hosted from FileMaker Server?
Especially with the currently supported versions of FM, I rarely find any reason to not use the Separation model. There are very few things that don't work, or are difficult to get used to, when using the SM. User accounts is one thing. There are ways around that though. If you can, External Authentication is probably the best solution. Short of that, it really depends on how your users and your organization need to secure the development. It's not uncommon to use a low level, auto-login in the UI file and let the data file pick up the user account security login. There are some things you will need to work through with that, but it works nicely.
Another benefit is the flexibilty of deployment. You can host both the UI and Data file on the server, or just the data file and let the user download the UI to their local machine ( or practically any combination in between ).
The only other thing, off the top of my head, that takes getting used to...is remembering which file you need to make any data changes to.
We are using FM10. The current solution is hosted on FMS10. We are looking to go with IWP or custom web publishing in FM12.
Authentication is a mixed between external authentication (tied into our Open Directory for internal staff) and local authentication (when volunteers create a profile with us, a local unique login credential is created)