It's not clear from your post exactly what your issue is. I've run separated solutions that didn't see any difficulties on iOS. Maybe if you let us in on what your issue is, we can provide some suggestions. Is it the security model?
I'm with Mike on this. I'm using separation-model file on iOS GO devices without any issues once the appropriate layouts are added. Tell us what you are running into with Security.
The only real difference for security settings is the enhanced performance by using the Extended Privileges to adjust/edit the "fmreauthenticate0" setting to help deal with interruptions. The main difference on that for Separation Model file systems is it's easy to forget to set that in boht/all files.
In the little bit of testing I find that I'm asked for credentials after opening the file. My users are used to the domain and security settings taking care of the login and access. I'm assuming that I could take a single login event and (with scripting) use that to access other files that the current file may be working with.
I'm sure that there are other issues that I could avoid if I had a decent how-to guide. The essential question: Is there a good Separation Model for Dummies write-up out there?
I'm sure google will get me going, but I'm sure that someone here or even FMinc has put something out that nails it.
Thanks for your help
The attached migration guide includes a primer on the Separation Model. May be of some use.
However, please note that iOS does not have a domain client. You can't authenticate into the domain using these devices; hence, you can't use an AD / OD External Server authentication to log in. What your users are "used to" - not having to put in an account name and password - simply won't translate to iOS. It's really not a matter of whether you use the Separation Model or not; it's a question of authentication. You can do one of three things:
1) Create a generic opener file for all users that automatically logs the user in using a default account. Dangerous; anyone who gets hold of that opener has that level of access to your database. Also means you can't differentiate between users (so Get ( AccountName ) does you no good).
2) Create a specific opener file for each user that has that user's credentials embedded. Only slightly better than option 1. If nothing goes wrong, you can differentiate between users. (But something always goes wrong.) Still has the problem of other users getting hold of the file.
3) Tell your users that they just need to get used to putting in an account name and password when they're working on the mobile devices. Explain it as a limitation of the technology (which it is).
As always, great advice and wisdom from Mike_Mitchell.
I have been using a number of separation files for FMGo and Web Direct on a large file for a few years to provide live database info to the staff and the customers. It has worked very well. For the public, and their limited level of access via Web Direct, I have just used the log in without password method (auto open in Web D with the guest acct).
Maybe this would suit you, notwithstanding the limitations outlined by Mike.