When hosting a solution like this do both files need to be hosted?
No, but they often are. I have no clear cut indications that suggest keeping the interface file local is a better or worse option that hosting it. With some layouts that have a lot of layout resident graphics, they may update a touch more quickly than when it is hosted as that information now does not have to travel down the network connection to the client computer, but now you have a more complex task when it comes time to roll out a new copy of the interface file and you need to make sure that all users got it and are using it instead of the original.
Often the quality of your data connection will determine which option works best. If you are using an iPad to connect via 3G, for example, that local copy of the interface may make a lot more sense than over a decent quality local area network.
Fortunately, it's not an either/or proposition. You can easily try it both ways and evaluate the actual database on the actual hardware involved and see if there is any advantages to using a local copy of the interface file.
Note that handing out physical copies of a database file can be a security risk as there are tools that can "hack" a file once someone has a physical copy of the file. If you use this option, you may want to use FileMaker Advanced to remove all [full access] accounts from the interface copy that you distribute to individual users.
Do I open the Data file and in hidden mode, and show the user interface in the open remote?
That's how I would do it.
Also, I was thinking of possibly creating multiple interface modules that are basically set up as the roles. The different interface, would only contain the layouts and scripts needed for a particular role.
Now that's really an intersting issue to think about. You'll find that you have trade offs with this approach. If you have to make an update that only affects the layouts used in one role, this has advantages, but every time you have to make a change that affects multiple roles, you now may have to make the same change multiple times. Keep in mind that with security settings, you can limit each user's access to only the layouts and data appropriate for that individual user and such security settings, while less complex when you split up the interface will now have to be maintained in many more files than just the interface and data files.
Note that this last issue has been discussed a number of times across the FileMaker community as there is no clear cut answer. It's more of a developer preference combined with evaluating the needs and function of a specific project type of issue.
Well let me try this again. Thanks for the insight Phil.
My comment didn't take, and it was quite lengthy, I'll retype it next week as I'm about to be gone for the week end..
One of the things I'm also wanting to do this for, is once I start to market this, I was thinking of creating different interface packages. The company I originally designed this for uses quite a few options that I'm sure not everyone may need or want, so I want to build interfaces packages that only incorpaorate some of the features, and others that incorporate more. If they want an upgrade, I can simply replace the interface files, the layouts will be differnent and now more options will be available to them.
The full package:
Accounts, Interviews, Census, Census Statistics, Client Payments with quickbooks integreation, Food Stamps, Multiple facility locations, Notes for all tables, Fleet Vehicles, Vehicle Maintenance, Vehicle Expenses, Vehicle PM Scheduling, Calendar, Todo's, Staff, Timesheets, Merge Letter print System, Merge Letter email System, SMS system, Documents.
Client Payments with quickbooks integreation
Multiple facility locations to single location
Notes for all tables,
Fleet Vehicles, Vehicle Maintenance, Vehicle Expenses, Vehicle PM Scheduling,
Calendar, Todo's, Staff, Timesheets,
Merge Letter print System,
Merge Letter email System,
Do you think this would be feasable? I know it would be a lot of layout set up, but as long as the data file had everything in place, it would just be a matter of chaning the interface files with more or less options.
Modular "mix and match" design is certainly feasible and I'm not about to give you a simple yes or no as you'll have to weigh the pros and cons for yourself.
The alternative approach is to use the method FileMaker Inc. uses when you purchase FileMaker Server. You actually get FileMaker Server Advanced, but the license code provided limits you to only the features specified for FileMaker Server. If you then contact FileMaker and "upgrade", they send you a new license key that unlocks the "Advanced" features.
In terms of your design, you can set up a "key field" where issuing them the key set's a value in a field that your scripts can detect so as to unlock access to additional sections of the interface file.