You don't have to export to import. You should be able to just import. Data separation would allow you to replace an interface file with a new copy of the same file without importing data.
I am not familiar with interface files. Can you elaborate on what these are? I can do the research from there.
It's a FileMaker file with no data--only external data source references to tables in a second file--the data file. Search on "FileMaker Data Separation" to learn more.
Some of my confusion regarding using an interface file is how do new fields get updated in the interface file as new ones are added into the display file?
This solution gets pushed out to multiple users and each have their own, different data but all use the same fields. Putting this on a FM Server is not an option.
Found this great, short video on this. Does not answer if a new field is added now the data file gets updated but I will play around with that to see if that is more dynamic.
Thank you Phil!
It makes no difference if it is a rutntime solution.In order to update multiple "single"user" databases you can either use the separation model as already being proposed or you must make an import - export procedure or even use a sync procedure.
One thing to concider if you go with the separation model is that it is better to have all your tables fixed (and the fields) and just update your layouts and your scripts.
Data separation reduces the need for data imports, it does not eliminate them. If you add a new field to a table, you have to import records as you will have to update the data file as well as the interface file.
While a viable solution the separation model has certain limitations and makes the developing of the database more complex. Creating a backup by exporting all records will also offer an extra security layer in case the database gets corrupted. This backup should be created in the user's Documents folder.
It will require a unique ID for each record and an extensive export script. Your picture container field will need to be exported one record at a time. Create one file per picture and use the unique record's ID to create the file's name.
After re-importing all records into the new version query each record's ID to match it with the corresponding file name of the exported picture file and re-import it into the corresponding container field.
This is an obvious problem when developing runtime solutions.
It would be better to recognize the problem and select and test an update process before releasing your runtime product in the first place.
Yes, obvious for a level 14 maestro - I am sure you picked up a lot of tips while going from 1 to 14.
I have outlined elsewhere the approach I have used with frequent updates to runtimes by the "mom-and-pop" users of my client. A couple of major points:
. I use the import approach and stick with only one file.
. Have the solution create timestamped backups as a matter of course.
. Send them a new file that upon opening asks for them to point to the location of the backup folder.
. The solution finds the last backup and imports all the tables.
. It then renames the old solution, so it won't get used accidentally.
This will work with Runtimes without an issue. Obviously, there are a lot more moving parts to it than that, but that was my approach for many years, and it worked really well. Another thing I do these days is to use UUIDs everywhere. If not, with a solution like that one you would have to reset all the serial numbers after each import. Not too big a deal, just not necessary anymore with UUIDs.
Another thing about Runtimes is that you don't need to create a new Runtime for each new iteration. Just edit the actual FileMaker file in the runtime and when you put it back it will just work. You can also copy a Mac runtime application file into a Windows runtime (and vice versa) and it will just work. Just be sure the they are both created with the same runtime key.
I agree with all
The only problem is that runtimes are in the "ending days" since filemaker 14.....
1 of 1 people found this helpful
Oh, I know that a lot of people are enamored with the promise of the Separation Model. I never found that to be quite as easy in reality as in theory. FileMaker just doesn't work that way. If you have to change ONE thing in the data file you are hosed with that approach. So, you might as well send them a brand new file with all the new bells and whistles working perfectly and just suck in all their old data.
Another thing that worked for me about the import approach is that I could use the import script to do any other housekeeping functions in case there were issues with the data that had cropped up, due to unpredicted user behavior or even deficiencies with developer wetware.
 There are ways that the more advanced Sep Model partisans get around this, but it it requires a sufficiency of extra fields and some fancy high-level schema tricks. I'm not that smart, so I brute forced it.