Run time data files have exactly the same structure as regular filemaker files. They just have a different file extension specified during binding. Since a runtime system can include multiple filemaker files, just add a file to your system with an import script for importing records from your main file.
The resulting file can be opened by filemaker pro and data from it can be imported into a dofferent filemaker file if you need to.
As with all scripted imports, it's much safer if you can use identical field names in both tables so that you can specify the matching names option for your scripted import.
Thankyou for taking the time to answer my question.
I would just like to make sure I understand your answer.
1. My Runtime needs to have a second file bundled with it for the purpose of importing records. Could this also be a table or multiple tables dedicated to the import? And the reason for this is that the imported records will be read only? I can then use setfields, relationships, or some other method to get the data into fields that can be edited if needed.
2. I need to decide ahead of time what the filepath will be so that I can specify it in my import script or can the filepath be input via the ShowCustomDialog script step? I would likely keep the runtime file in the same folder as the import file for simplicity.
3. Anytime I want the latest data from my Desktop I would get a copy of the fiile I used to create the runtime from my desktop, place it in the approiate folder on the laptop and allow it to overwrite the existing file. Then run my import script to get the data into my runtime.
4. To get the latest data from the runtime residing on my laptop onto my desktop I would make a copy of the runtime itself and FM Pro Advanced on my desktop can open it just like any other FileMaker file? I would then import the data using the same method as above.
5. Rinse and repeat.
Do I have it about right?
Hello. My database is still a work in progress but I made a runtime to experiment with. I found more functionallity than I expected. Both import and export are available in the file menu. Also available is Save a Copy As. This allows the creation of a .USR file type that (as you said) can be opened in FM Pro with full functionallity. Even layout mode is available. I guess you wouldn't want to add any fields because they would not be available in the Runtime. But you could rearrange layouts to take advantage of a larger desktop screen. I could then use this as my desktop version and import from the .USR files I create using Save as in the runtime.
Import happens 1 table at a time so I can see why you would want to script it so that one button click can import all tables at once.
Export is also one table at a time when you go through the File Menu. Save as is a quick way to send the whole database but I can see the advantage of using Export. As the database grows it might become impractical to email the whole thing. With export you can send only the current found set of records.
I think I will be able to do exactly what I wanted to do.
PhilModJunk, I have read many of your posts on this Forum and have learned a lot from doing so.
Thank you for sharing your FileMaker Pro knowledge.
One detail that can lead to an unpleasant "suprise" when scripting imports: If you have serial number fields in these tables, you should also include code to update the serial number after import so that any new records created will not have serial numbers that match one of the imported records. The script step, set next serial value can be used to update any serial numbers.
Another "gotcha" is a long standing "bug" that only affects scripted imports when you are unable to specify the "matching names" option. If that's a possibility, please read this thread: Data loss bug : Spontaneous and erroneous import matching of new fields in specified imports !
I don't use auto enter serial numbers because I like my record numbers to be sequential. I have a script to set/reset my record number field when a record is created/deleted. Only works on last record though. Does not loop through if a record is deleted in the middle. In this solution you would not want to delete in the middle. It is just there in case a record is created by mistake since I have navigation buttons that create a new record. I guess I could use the script step you referenced above to do the same thing with an auto entered sequential field. But you have a good point about things getting funky if imported records have the same Record# as existing records. I believe the imported records will be the found set after the import so it shouldn't be too hard to set up. I can grab the current last reord number as a $Variable before starting the import then loop through the found set using SetNextSerialValue assuming I switch to using auto entered serial as my record number. I think I did that because I was experimenting with FM Touch as the remote collection tool and it did not support the SNSV script step. I like my record numbers to be 1, 2, 3 not 1, 2, 4. I am now playing with FM GO which is much more robust.
The other "gothca" you mentioned won't be a problem for me because I plan to have matching field names. Data will be excanged between identical tables. But now that I know about that bug in the future if I need to exchange data between two dissimilar databases I will go out of my way to make the field names match at import. Even if I have to create a new table in the exporting file and bring the data into fields with names that match my destinatin fields.
Thanks for the info.