are you referring to data source path for the data files or any referenced sources?
i don't think you can use fully dynamically use a $var - as far as I understood on changing the path you need to reopen the file who has the dynamic reference embedded (unfortunately). Makes kind of sense because the temp files won't be swapped dynamically ..
so $$var should be in place and the path var initialized before opening / referencing the intended data source.
Hi Tom & FileKraft..
Thanks for your response..
I checked out the process described in FileMaker 16 - Dynamic Data Source
..and set up a simple interface file and two data bases etc. It worked OK, but the two data bases were not data-separated, so I'm not sure (yet) how things would work with data-separated files.
My initial question was more related to the actual process of separating the data from the UI, where a copy of the application is created (Application Data) and the data path for the UI Files (Application) is changed to the new data file.
Looks to me that the Dynamic process won't work if we use, say, "$Data" as a new path since we have to have the new data (Applications Data) already set up as the "$Data" source..
Am I confused (or just confusing) !
Besides any other problems, remember that a script variable ( $var ) disappears at the end of a script.
A file reference is a file reference. Call it "Data-separated" or not. It sounds to me like you saw it work, so now I'm confused. What is the question?
And yes, if you read the AppWorks article linked above, you can use a local script $variable to set the data source, if you do it at startup. I haven't tested that though.
it doesn't make sense to use a local $variable. you cannot assume that it is implemented to keep the file reference once used just during that script run. Even if you get it to work for an instance. There is a lot going on with caching and temp files etc.
FM documentation suggests a global variable and from an implementation stand point it might make more sense IMHO.
You are right re using the global variable, which is what I used when testing out the example I referred to earlier.
However, the example (and at least my test) involved accessing a couple of applications that were not data-separated. If these applications were, in fact, data-separated, how would this example work to ensure that the data for each of the applications is properly found?
Have you or any folks you know tried this out yet?
Makes no difference.
Hi Tom.. my question at this point is if a global variable can be used to dynamically set the data paths to applications that are data-separated...(see (8) and (4) above.
I've started to test this out a bit, but am thinking that someone out there will be smarter than me on this!
Your continuing help is much appreciated !
Hi Bruce..To me it would appear that the process would work OK to get to the UI side of a particular data-separated application..but how does the applicaition itself know where its data is located??
You are right; you are confused and confusing.
Probably best to create and upload a super simple example.
If you are trying to specify a path in a variable - then what did you write into the variable?
1 of 1 people found this helpful
Hi Bruce..I followed the example outlined in the following link:
I pretty well duplicated the code provided, and it worked OK. I was able to dynamically switch from a layout in "Application A" to the similar layout in "Application B" based on the ID of the user on re-login. Here is the actual code provided in the example .
Applications "A" and "B" are not data-separated.
If I try to do the same thing with two data-separated applications, how are the paths to the data recognized?
Late to the party on this one, but we've successfully tested this on the separation model and also a 'log out', 'log back in' so selected users can effectively swap their data files 'on the fly', using a dedicated handler file to do this, to swap which system they are logged into.
We've an old legacy system we support that has been triplicated and now consists of about a dozen data files per version, any changes have to currently be carried out 3 times on the 3 separate systems in pre-FMP v7 type design (scripts calling scripts between files).
We're investigating whether we can setup a new single interface file for all 3 systems, reduce the number of data files and then only have to maintain a single UI file.
So far so good!