Separation Model. Too hard?

[Greg Hains]

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

[Fenton]

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.

[Greg Hains]

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?

Cheers,

Greg

[David Jondreau]

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.