In data separation you have two files: the data file and the gui file.
The data file needs all of your active user accounts. You can control access to your data by creating or deleting accounts.
The Gui file needs at least ONE active user account. If the account(s) it contains are deleted from the data file, it cannot access the data file.
You can make as many gui files as you want and distribute them. For instance, a custom gui file for sales personel, one for the warehouse, one for management. Each would have its own specific layouts, scripts and TOs.
Or you can distribute one file with all accounts, not the safest since it is easy for someone to acquire one or more passwords.
I recommend deleting all un-needed accounts from a distributed gui file if it is this monster file. For instance, delete every account except sales when you are giving the file to your sales staff, etc.
You should also use Advanced to delete the Full Access account on the distributted copy but not on your own, of course.
Of course the user of the gui file will need access to the data file.
The big benefit of the two files is that you can update and distribute the gui file and overwrite it without affecting the data file. If you try to distribute an update that contains data and gui then there is the hassle of importing, syncing, etc.
There is no simple answer and no one factor that will cause a choice of methods.
@Jack, I'm having trouble picturing how a data file of all accounts and a GUI file of just one account would work. Seems like that would require sepearate and distinct copies of the GUI file for every account--which would seem to make this situation worse rather than better--but I'm all ears if you have a way to make that work without such GUI files.
I'd define an accounts table of accounts and passwords in the data file. When deploying a new copy of the GUI, a script can run through the records in this table and create a matching account and password in the GUI file as a one time update immediately after deploying the new GUI. This requires that you use scripts to manate security so that the scripts can log the addition/change/deletion of accounts in that table each time such a change is made.
For added security, you might look for a plug in that can encrypt your passwords in that table or you can add a modest increase in security by adding your own "scramble/descramble" calcs so that only scrambled versions of the password are stored.
Guys, thanks for your feedback. I am struggling to find an ideal solution here. One underlying problem is that in the data separation model the tables do not appear in the data security setting for the GUI file ( I assume because they are in the Data file). Conversely, the layouts do not appear in the Data file (because they are in the GUI file!) A possible approach would to be have a generic auto login account in the GUI which is not in the Data file. My understanding is that FM will then force entry of account credentials when it attaches to the data file ( cos there is no matching account). so you maintain all account info in the data file and a single generic account in the GUI. This means you have to rely on you table security settings in the data file, as you cannot set layout or script restrictions there ( neither exist in the data file) I'm sure there must be holes in this approach, and I would welcome feedback. The ultimate objective is to be able to distribute a generic GUI file to all customers using your product, without having to worry about account settings. Regards, Tim
You seem to have overlooked creating a new TO and pointing it at the data file if you are creating a new file or double clicking on the TO and pointing that at the table in the data file. The new TO will be italic if you do it correctly.
Tommorw I will write a blog post on how to do this.
Since we now live in an age where a client might have many mobile users with iPads and iPads, we need to rethink our security and I have been giving this a lot of thought.
Just on the issue you raised I will ask a question:
Which is wiser, sending all these iPads into the field with a file that has all of our accounts in it or sending them with a file that only has their own account info in it?
More work for the developer but is it THAT much work?
Let me narrow down the topic to an iPad or iPhone in the wild that has a file that will work with your file on the Server.
First you create the Big Momma file that has all of the accounts in it. Now you want to give Joe Salesman a copy of this file. Joe is going into dangerous areas where your competitors (or foreign governents) might kidnap him, etc. So, you want Joe Salesman's file to only contain Joe Salesman's account and password, right. (Let's not consider what Joe Salesman might do if he got other account names and passwords.)
Now the GUI file has been set with all of the pointers to the server, etc. and opens the Data file.
How the heck hard is it to Clone or Duplicate the file and delete all of the accounts other than the Salemsan's account? Let's see, one minute at best? To be safer I'd remove the Full Access account using Advanced. So, three minutes total... So, if you've got 100 salesmen in the field you can strip out everything but the Salesmen's accounts in 3 minutes and send all 100 a new copy by email.
For supersafety I mighj design the Relationship Graph to use the colorized text fields to show the files needed for the various categories of users so I can quickly delete the superfulous ones as an added extra but this will take some time to debug. Hmm, how about creating customized data sources for those categories and only need to delete those aliases? Would that work.
Maybe I'm just too darn advanced in my thinking...or at least think I am... :)
I get what you are saying and don't disagree. I just wasn't thinking in terms of placing the interface copy on the client machines--as you well would want to do at least with iOS devices as I imagine that will give you better performance in bringing up some layouts.
I can go you one better on the issue of one account per copy--which could easily add up to a great deal of time if you have more than one client using your solution and if the different clients have added/changed accounts in their copy of the solution.
Use a script to set up the accounts in the individualized user interface files from that table of accounts/passwords in the data file. Not only will this automate the process and save time/avoid mistakes, it can now be done by the client instead of by you. This can be especially important as your client may have created accounts and passwords on their copy that you know nothing about. You give them one copy of the file with a generic account and they open it and run a script to get one copy of the GUI file for each account in their data file.
I did create a script using a table to add and delete accounts so this need not be 100% manual.
Your idea about clients adding accounts is a problem to deal with.
My Accounts table could be in the main data file, well, it should be right.
Each account name has a checkbox for keep or delete or new. The script deletes all account names marked delete and adds the new ones.
The DATA file could be custom built for just the desired accounts using this idea. ie find all xxxx accounts in Data file and add to this GUI file. Eliminates manual stuff. Or the builder could check a cb for the accounts to add.
I used this Accounts table to quickly delete accounts, say an angry person no longer employed, and to add accounts and this greatly simplified the process for a client.
I'll discuss the Login file I finally found an answer for in my blog...
In essence this unique DATA file could be used on the iPad to login and would be tied to the PersistentID so it would not wander off and also be limited to the iPad users account and could be generated quickly and emailed and even an experation date for those times you want to limit access to Monday through Friday, 9 to 6... more fun, right...
We do need to give more attention to the IOS devices since they are in the wild and doing unusual things with the Cloud...
Regarding place all of the files on the server, a good idea.
Then an opener file could be used to open those files and then quit itself. I did this for a client before his internet connection. Each person had their personal opener file so clicking it would send them to where they wanted to be: front counter sales, bookkeeping, sales, warehouse, owner, etc. The opener file did not access the data base only performed a script to open the designated file and if needed would before a designated script say perform script x in file x. Made life easier for everyone.
The same opener type script could be used on IOS devices to open the remote file. And if lost the account can be deactivated.
Now we can lock a file to a computer so it can't be used on another one! Finally...