Any ideas on this? Is it only possible for users with the Privilege set [Full Access] to manage external data sources? What a shame...
Why would someone who does not have [Full access] need to? What problem would that solve for you? (that's a pretty heavy duty design change and if done wrong, could seriously scramble the function of your system.)
So, I'm using the data separation model to create a solution that manages paperwork for a project. It will be used by many different users on different unrelated projects. I want to be able to treat the Filemaker solution (UI file) like an "Application" and treat the data files like interchangeable "files" that a user would "open" in that application. So a user can be browsing data for one project, then switch to a different data set to browse/edit data for a totally different project.
This is the same type of thing being discussed here but also with no conclusive solutions. As I say in the last post in that thread, I have been playing aliases and lots of other things, but can't get it to work. The mechanic of it works great when I (as Admin) just swap which file I'm using as an external data source. All the project data refreshes and all is well. My users are smart and I would have no problem trusting them to load new data files by managing external data sources on their own, but I don't want to give them the ability to edit layouts and scripts and certain tables so they can't all be on [Full Access].
Is there a better way to do this same thing? It seems like a really useful concept and I am surprised it doesn't seem to be more common. If we were allowed to use variables as external data sources, it would all be fine, but we're not. Do people do this some other way?
The "better way" in my opinion would be to put all the project data in the same tables of the same file and not try to redirect your data source reference. There are many tools to use within FileMaker to keep the data from different projects segregated when your users work with the data. In FileMaker that's a manual change lacking any kind of "safety net". If your user makes a mistake, they could seriously scramble their data. And this cannot be scripted either. I would not allow anyone but someone who knows how to design FileMaker database to make changes to the file via Manage | External Data Sources.
I suppose the alternative approach is to take the "separation" one step further and issue separate copies of the GUI file, one for each data file set. (And I'd keep the GUI File and Data file set together in the same folder so that the same "relative path" reference works for each deployed copy of this solution without need to update these references.)
Yeah. I understand both of those options.
Unless I figure out a way to make this work, it seems like I'll probably have to settle for option #2, but It makes me very sad.
The thing is, my users will all have their own data files that I will have no access to. The appeal of my intended approach is that I could issue updates to just the UI file with new features and improvements. A user would "install" it and then be able to use it to open and access their existing data files and they'd get all the updated UI features. As long as the features didn't require changes in the underlying data structure, this would work great.
And why would that require allowing users to redirect? With relative paths, you just drop the UI file into the existing solution folder. And why would they need to have more than one copy of your solution?
This just doesn't look like that big of an issue to me...
Each user will work on many of his/her own projects. So that's why they'd have multiple instances if I went with option 2. But I do take your point about how they can just replace each copy of the UI file with the updated version. It's a bunch more steps for them, but not impossible.
The other idea I just had (in the shower, where I have all my best ideas) is to actually let users be [Full Access] but use my custom menu set "Show when" conditions to limit what they can do. So if Get ( AccountName ) = "Admin" then options like Manage Layouts would appear, and if not, they wouldn't be on the menus, so no one would be able to access them. Maybe that's all the permissions I need...