It's possible. Export records can export a single record or a group of records as a text file from one such copy and Import records could import the resulting file into a different copy of your runtime.
This can be scripted to the point where the user simply clicks a button and uses the dialog that opens to select the file to import.
Are there any downloadable examples of this where I can see how a script might function?
Also, would an alternative be to have all the records stored in 1 type of Runtime solution ('records') and users use a second solution (eg. 'calcs') to do work on the records. The later remain in 'records'. That way all users could have access to all records without having to export, unless of course they were sending the record to a different server domain or institution.
Could the latter work?
I do not have a downloadable example that I can share.
Many of the details will depend on what exactly you are trying to accomplish with this export, then import process. How, for example, does one user deliver that exported data to the other user? An email attachment perhaps? Or a shared folder in a cloud service such as Drop Box?
The Export Records script would be very simple
A) Perform a find or use another method such as Go to Related Records to set up a found set of just the record or records to export.
B) If needed, specify the location and file name of the file to be created by the export in a $Path variable
c) Do an Export Records to export the data.
The Import Records is more sophisticated;
A) Use insert File with the store a reference option specified to open a dialog for the user to select the text file to import. This inserts the reference (filepath) to the file into a container field.
B) Check for an error code indicating that the user clicked cancel and exit the script if they did
C) Set up a $Path variable with the file path and file name extracted from the container field
D) Use Import Records with the $Path variable to import your data from the user selected file
For more on $Path variables, container fields and the script steps that can use them: Exploring the use of a $Path Variable in Scripts
Also, would an alternative be to...
I really have no idea what you would accomplish with that. There's just not enough info on what you are trying to do to be able to answer the question.
Thanks re. the first part.
The alternative would work (at least my plan of it) as follows:
- A bunch of users, using the same Institution Server domain would each have a copy of the 'Calc solution'.
- 'Calc solution' would, be able to generate patient records, recall them from or save them to a second database, 'Patient solution'.
However, I'm not sure how I would both vary the number of users/ 'Calc solutions' and link them to the 'Patient solution'.
I don't see any way to make that work in a runtime. Runtimes are specifically limited by design so that they can neither serve as clients or hosts of a shared database.
Thus, importing data from one solution copy into another is possible, but somehow accessing a hosted or shared common file seems pretty problematic. It might even result in damaged files with some design approaches.
The fact that this is "patient data" makes this even more of a concern as you don't want any issues with how data is handled to result in inaccurate data being used to manage a patient's care.
You'd be much better off to host your solution from FileMaker Server and have each user use a network (wired or WiFi) to connect as hosts to the hosted database using either a) a web browser (if you use WebDirect to publish to the web), b) FileMaker Pro (on computers or Window OS tablets) c) FileMaker Go if using iOS devices such as an iPhone or iPad
I'd considered hosting. I think:
1. Cost may be prohibitive in that users won't invest in FM Pro. FM Go is possible, but that limits to iPads?
2 Healthcare institution probably wouldn't invest in FM server and wouldn't permit patient records to be held by a 3rd party. I'm nowhere near knowledgeable enough to know whether FM Server can provide asymmetric data transfer, ie. the user's FM makes a 'calculation call', get the answer, but never releases patient data.
I'm not sure if there's a solution to this.
1. It can be expensive to save money. (Cutting costs may reduce capabilities resulting in much higher costs in the long run.) FMGO can be used on iPads, iPhones and iPod touch devices.
2. Yet one "information failure" leading to a law suit could exceed the total cost of setting this up by a very large margin.
Your client devices can be set up so that while they can access the data, none of the data is stored on that device. This requirement pretty much makes your original idea of importing and exporting files a "no go" as that would store patient data on the individual devices instead of keeping it in a single, hopefully secure, server where others access the data but do not store local copies of it.
I assume the latter entails the user institution having a copy of FM server along with the solution?
Or they contract with a FileMaker hosting service to host the database for them. (Or you set up your own site as a remote host of it). But both of those options move the data out of the direct control of the institution and that raises its own set of issues.
But thank you for the insights.