1 of 1 people found this helpful
I think you are describing is the conversion from a single file to the Data Separation model. When you are done, you have two files, one that is the interface and one that has the data. At least initially these files are close to being identical until you change the references in the interface file to point to the data file. Once that is done you can modify the interface file and as long as no changes are required in the data file and simply swap the interface file for a new version.
There has been a lot written about the Data separation model and there is a large segment of the developer community that love this method and use it very successfully.
Thank you Bruce,
I try to explain the question more clearly.
I'm speaking of a data separation model (that I've already used a lot) but the difference is that the separation is in the file itself.
Imagine that the filename is "Contact Management.fp7"
In the external data sources I add a source Contact Management that point to the file "Contact Management.fp7" itself
Advantages / goals
1) In this way I can keep the development in a single file (source file:Contact Management.fp7).
2) I can install a single file on a iOs device (source file:Contact Management.fp7).
3) I can instal a single file on a iOS device (or PC), with the application logic, and reference it to an external data source (ex.source fmnet:/10.101.2.231/Contact Management_data.fp7).
In this scenario do I have a better performance due to the fact that the interface is installed locally on a slow GSM or VPN connection (THIS IS AN IMPORTANT QUESITON)?
4) I can use a "normal" separation model installing two files "Contact Management.fp7" and reference it to an external data source ex. "Contact Management_data_local.fp7" that contains the data and that "Contact Management.fp7" is pointed to (source file:Contact Management_data_local.fp7).
I hope that I've explained myself.
I attach the the Starter Solution "Contact Management" modified in the external data sources and relationship graph.
I've made some testing and it's works fine, but before adapting a complex solution to this logic I'm searching for advice ;-)
Contact Management.fp7.zip 139.2 K
1 of 1 people found this helpful
Is your goal to be able to quickly change the reference for the external tables [which in the current case are in the actual interface file]?
Since you've not used any tables in the actual file, but all TOs are referenced as an external source, I am not sure what you gain. It seems like a extra layer of complexity is added.
Your file path for the external references
would seem to always use the first instance (itself) unless the file is no longer named Contact Management. Or do you plan to remove one of the references should you deploy the file(s) separately?
Perhaps adding a large group of records and comparing this method vs a more standard method would give you some answers.
yes the goal is to deploy the file separately removing the "itself reference" (in the example file:Contact Management.fp7) beside being able to deploy the solution on a single file (for example for installing it on iOS device) - and develop the solution in a single file -
In the real solution, not in this example, some tables are containing the interface data, images, text… those tables will remain in the file. So I suppose that accessing the solution data from an external data sources (fmnet:/ ….) from an iOS with a slow connection will speed up the process (the interface file is installed on the device, the data are on FMP server)
It sounds like you are doing exactly what many of us do during the construction of a Seapration Model file set -- build it in one file, but with mulitiple file references, one of which gets repointed to the external file when we save the copy of the file and rename it to be interface or data.
However, if the goal is to have a served data set, it makes more sense to me not to put the interface on the iOS device, but on the server itself. This way you need only update the copy on the server, without having to replace files on multiple devices, whenever there is an interface change.
I would recommend put it all on the server, and distributing only an Opener or Launcher file to the iOS users. The Launcher file simply points to the interface file on the server via the IP address and opens it via a script which is set to run On file opening, and this file won't have to be changed on the iOS device to deal with upgrades (unless the IP address changes or the files names on the server are changed).
In theory, I agree with the data separation model, or some varient of it. Personally, I'd rather see all data stored outside the solution file, in as simple a form as possible (csv records, text files, media, etc.) and only the layouts, relationships, etc. in the solution. I don't know how much having two solution files (one containing only data) with all that overhead helps.
But I do know my clients. In pre-FMP 7 days, when each file could hold only one table, they were always losing tables or overwriting them, or having some sort of problem with the paths not resolving properly. Not EVERY client, but enough that it was a hassel. I'd rather deal with doing a data migration for every new build or corrupted file issue. It's probably about the same amount of work for me, but more straightforward, so I can just knock it out when I have to.
That said, your actual milage may vary. If you have one client, or a few, that have a decent IT department, and you're going to be modifying on the solution file on a regular basis, I'd say go for it. I have done SQL front ends in FMP and it can be a bit of a pain to set up, but the performance hit is tollerable, considering the vast amount of data being pulled in. So I wouldn't expect performance to be that much of an issue.
Thank You Stephen,
the solution file is 8/9 mb without any client's data (just logic and interface), and it's 20 mb with clients data.
If I manage to install the logic on the iOs and leave the data on FMP server I guess that the performance should increase on a slow connection. (THATI IS THE QUESTION!).
I could in any case use a pointer to open the solution that checks if the solution logic is installed on iOS is the last one (eventually replacing it using a container field) but using the local solution logic to access the remote data without the need to download the interface and the solution logic on a slow GSM connection.
I suggest anyone interested to iOS and FMP to view the webinar
Considering the file sizes, it does seem that installing the interface locally would speed up an iOS WAN connection's response. But I wonder if it makes a difference during session use or only when loading/opening the solution at the start of the session.
If gain is only at startup, I would still consider the issue of needing to update interface files on iOS devices when they are upgraded. Installing a local file if not current has been addressed in some of the webinar info re GoZync. They present a method to test if the local file is latest rev and update if not most recent.