Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Separation Model. Too hard?

Featured Replies

Hi.

Now that I have probably sounded like a goose with that title, I would like to ask about the pros and cons of an idea I was toying with.

It's not that I'm too lazy to setup the SM for my solution, but working the other way, what do you think about having a single Filemaker file (app and data), but running it for several clients.

So, for example, client 1 signs in and accesses their data, and client 2 accesses their completely separate set of data. It would need to be cleverly done with scripts so none of the data crosses 'over' but would make database maintenance a lot easier.

I know that file size may be one issue, but would security be difficult to manage?

Would one have it so that they (each client) accessed a set of tables (of data) specific to them? I find more questions the more I explore the idea.

If somebody could throw me a few brief ideas about how this would or would not work, Id be grateful.

Cheers,

Greg

The issue is not really security or separation so much, IMHO. It is speed. The only safe way to limit access to records is to use the Record View restrictions in Accounts and Privileges. This makes the database many times slower, for almost everything, since FileMaker has to filter record access constantly, for Finds and lists.

What I could see working is to use the Separation Model, and have only 1 Interface file, which could them be sent to different clients. As long as each of their Data files was named the same, with exactly the same structure, then it would work. But exactly means just that. Every internal table and Field ID must be the same.

Once they became out of sync for any reason, the same Interface would not work with them, and could do some very dangerous things; scripts would see different fields; FileMaker targets fields by their Field ID, not their name.

  • Author

Hi Fenton.

Thanks for your reply - it has shed some light on the pitfalls.

The problem (for me) with the same-name data file is that (and I didnt mention this in the first place) was that I will be hosting this database on a central server for all clients. I was trying to make updates and administration easier.

Updating the interface file is easy - just email it out, but changes to the data file would have to be done for each client individually. Im not against doing work, but if I can make the whole process more streamlined then I will.

Have I just complicated it even more? :P

Cheers,

Greg

I'd love to hear who's doing this successfully.

It is the basis of all web apps...one central data store with all users accessing only their own data.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.