I have a database with a container field holding about 8000 references to pdfs. The pdfs are stored in a seperate folder. Is there a way to import these pdfs into the container field so the file lives in the database?
Thanks for any help.
A useful method is to loop through the records. On each record, export the PDF to the Temp directory, then re-import it into the field, this time *without* the "Store only a reference…" selected. You can usually get the original filename using GetAsText ( containerField ), so you can retain the files' original names during the transfer. So the script might look something like this:
Go to Layout ( some layout with the container field on it )
Show all records
Set Variable ( $path ; Get ( TemporaryPath ) )
Go to Record/Request ( First )
Set Variable ( $fileName ; GetAsText ( TOName::containerField ) )
Export Field Contents ( TOName::containerField ; $path/$fileName )
Insert PDF ( TOName::containerField ; $path/$fileName )
Go to Record/Request (Next ; Exit After Last )
Note: You will need to enter filewin: or filemac: (as appropriate) in the Export Field Contents and Insert PDF steps.
I'll give it a try
If you are adopting the new (since FM12) external storage option, when you change the field storage settings FM prompts you to allow it to transfer container data to the new setting.
Concerning this matter, I am interested in taking photos (which go in a related report) directly into a FM Go 13 file on the iPad, then transfering the file to the computer, storing the embedded photos when desired in a recognizable folder/file structure and converting the container content to a reference, so that when the FM file is transfered back to the iPad, it won't become a memory hog but the photos will still be available on the Mac (or Windows) for future reference as in possible report revision, etc.
I'm working on it now, but would appreciate any advice.
I suggest you investigate FM's external storage options rather than the previous "store only a reference" technique. If you use the older method then you have to manage all storage and references yourself, whereas if you use the newer method FM does this for you—although you would have to make sure it doesn't lose contact with the image folders it creates. As far as memory useage goes, the database is not bloated by external storage—FM simply references and displays images when called for—but the folder of images it creates obviously take up disk space.
I haven't done this myself using FMGo, but I would imagine it would all be manageable. I suspect that if you went about it in the right way FM would also manage the image transfer between devices. Someone else will probably post something more definitive on this.
Retrieving data ...