Jump to content
Sign in to follow this  
joelb

Insert Multiple Documents Into One FMP Record?

Recommended Posts

We have a claims database in our insurance agency. We are now scanning (to PDF) all incoming documents. We want to insert/attach these PDFs to their respective claim record in FMP9. A container field only allows one document. Is there a straight forward way to insert multiple document into a single record? Obviously, I could create multiple container fields, but we never know how many we'll need per record, so that won't work.

Only other option I can think of would be to create a second FMP9 table that holds a few fileds like Date, Description, Source, etc, and one container field for a single document. Then add a control (button, etc) to the layout in the main claims database file. When clicked, a script would add a record to the second file, associate it to the claim currently being browsed, and allow the user to grab a file to insert into the container field in the new record that was just added to the second file. This would allow the user to associate 1 to n records in the second file to the actual claim record in the main file. The associated records could be displayed in a scrolling field in the layout for the main file.

Any other approach(es) anyone can think of?

TIA,

Joel

Share this post


Link to post
Share on other sites

Your 2nd paragraph describes the process well. The multiple items would appear in a portal in the parent. If you have a lot of documents per parent, you could sort the portal descending by creation timestamp, so the most recently added is on top. You would likely only show the names and dates of the documents in the portal.

It would be my preference to navigate to the Documents table (or perhaps a separate file if these are lots of large documents), create a new record, set the parent ID (from a Variable set at the beginning), then Insert File, commit, then return.

[P.S. I moved this topic to Container Fields, from FileMaker 9. If it was about "appending to a PDF" I would have left it, but it's really just about container fields, or relationships.]

Share this post


Link to post
Share on other sites

Thanks for the feedback. I appreciate it. Are there pros or cons to using a second table in the same FMP9 file versus a separate FMP9 file? I plan to store file references in the Attachments Table, not the actual files themselves.

Edited by Guest

Share this post


Link to post
Share on other sites

If it's references then no, you don't need/want another file. I only mentioned it because "users insert multiple documents", if embedded, can lead to a very large file; so you might want to separate them.

Share this post


Link to post
Share on other sites

OK, I'm making some progress here. I now have a single file with a parent table for all the details about the claim. There will be one record per claim in this table.

I have a child table in the file that will hold the attachments, and a working portal to that child table in the main layout that displays the details of related records properly.

A button on the parent table layout opens a new window, adds a new record to the child table, and displays a layout tnat allows the user at attach another document to the claim.

But I'm having trouble getting my head around the way FMP handles data. I have mapped fields from the parent table into the layout that opens (against the child table) when the user clicks the button. I see the "double colon" (:;) reference so I know I'm pointing the layout object to the right fields in the parent table. But when the new window opens, no data appears in the fields that are mapped to the parent table.

I'm beginning to wonder if I actually have to replicate the fields in the child table and relate them all to their respective fields in the parent table? If so, yuck. That's not very normalized is it???

I have to believe that I'm missing something....

Share this post


Link to post
Share on other sites

You are likely missing something. If you are creating a child record, but neglecting to pass the Parent ID (via a script Variable), then setting it into a foreign key of the child, then you will not see any parent data there.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.