Hello, Paola. Welcome to the forum!
Yes, what you want to do is certainly possible. There are a few different ways to go about it.
1) You can insert the PDFs into a container field directly in the database. This option has the advantage of being relatively simple, and it's very transferrable from computer to computer. But, it also carries some significant disadvantages. It bloats the database (makes it get very large very fast) and increases the likelihood of corruption. I've also seen significant problems with converting between versions of FileMaker where files were embedded in container fields. I very rarely use this option
2) You can use the container to embed the file "by reference". This option avoids the issues of database bloat and corruption, but carries some other problems. If your users can do this, and you're on the Windows platform, you tend to run into path mapping problems - one user's "M:" drive is another user's "N:" drive, and pretty soon user X can't see what user Y put into the database. Gets to be a mess pretty quickly, so I almost never do this.
3) You can use admin-controlled path entry, where you use a separate field to control the path to the resource and allow users to upload the file to a shared directory. This can actually work well if you have an intranet where you can control access to workgroup directories and then tightly control access to the pathnames. (Use the Open URL script step to launch the resource.) I don't use this method very much, but have seen it used with great success when the conditions are right.
4) The most effective option, in my opinion, is to use 360Works's SuperContainer product (http://www.360works.com/supercontainer/). This replaces the functionality of the container field with a web viewer that stores the resource in a directory on the same server as FileMaker Server, and then points the user to it. It avoids the database bloat and corruption issues, but also handles all the pathname issues for you, so you don't have to deal with those issues either.
Thanks Mike for the answer.
One more clarification.
In the cases 4 (360 works di supercontainer), if you embed the file in the mode described above, if I delete the file on the server , the pdf is deleted also in FM? I need to linked pdf in the record of FM, but then, I want to delete them form computer and open/save/print only from FM. t's possible with the 4° solution?
I've done this by inserting the PDF as a picture. It's viewable and printable from FM. AND if you delete it from your drive, it is still in FM.
If you store the reference only and then delete the reference, I think you are not able to view it in FM.
ok. do you confirm me that this is still only possible with the 360 works super container? If I insert a picture file into a container field directly in the database (without 460 works), I view the document's image, but I can't open or read or print the file. is correct?
bdayqueen is correct. If you store the file "by reference" and then delete the reference, you can no longer view the file in FileMaker. This would be done by deleting the contents of the container field. Of course, this is true if you store the file in FileMaker - because the contents of the container field ARE the file.
To your other question, if you insert the file directly into the database, you generally can view it (double-click the container field and it will launch). However, this is dependent on file permissions. If the user does not have permissions to edit the record, then he will not be able to do this. If you use SuperContainer, you will have a little bit more control; you can allow viewing without editing. Also, if it's a picture, you may not be able to view it if it's not a supported type (I know JPG and PNG are supported; not sure what else).
Of course, you can also program a web viewer object to point to the PDF on an external directory, which will give you the same ability, but that will require more effort on your part - you'll need to go with something more like option 3.
If I insert a picture file into a container field directly in the database (without 460 works), I view the document's image, but I can't open or read or print the file. is correct?
If you mean that the file is embedded into the container field (i.e. not stored as reference only), then it's correct: you must export the field's contents to a location on your hard drive before you can open the file.
if you insert the file directly into the database, you generally can view it (double-click the container field and it will launch).
This only works with files that are stored on your hard drive and inserted into the container field as reference only.
That is not my experience. Not with PDF files, anyway. I just inserted a PDF file into a local database, embedded, and was able to double-click and open it.
Same thing with a server-hosted database.
I just inserted a PDF file into a local database, embedded, and was able to double-click and open it.
Why don't you post your file.
It's correct. But the problem is when you deleted from computer the inserted file.
With my FM 11, when I insert picture (jpg, png ecc...), I view the document's image, but I can't open/print etc... I can to export it, but my problem is that I don't want to have this document on the computer, but also in the file....
I try with supercontainer
I'm new in the forum and on Filemaker Developer Comunity, Best regards for All.
I have a solution running on Mac, i must create a new record in my solution, rename PDF with a register number and copy this renamed PDF to my Server. When is done, i must link this PDF to my record.
It's a rudimentary system but works.
I have three problems with it:
1. I can insert PDF multi page, but i can't print directly form Filemaker this multi page PDF.
2. If i connect from my iOS Filemaker to my office, i don't see this PDF, obvious, this PDF is on sharepoint, that i can't mount to my iPad. But i would like to know, if this PDF is stored on folder in the same location that the Database, can it works??? I need that PDF's are stored on different folder, by year.
3. I would like to know how i can do a automatic vinculation Register Number to "Registration Number.pdf"
Thanks for all!!!
You're going to run into the same problem with SuperContainer. Essentially, if you load the document from the asset management system (which is what we're talking about here - using FileMaker as an asset repository) and then edit it, someone will have to load it back to the database after editing. Otherwise, you still have the old version in the database. There's no real way around that.
Basically, you're going to need to design the workflow to either:
1) Educate the users that they must put their edited version back into the same record when they're done.
2) Create a versioning system that allows them to create, but not edit, the stored documents, then have them create a new record for each revision.
Which one you use will depend on the business need. But in any case, calling up the resource from out of FileMaker will NOT allow the user to edit it and automatically put the document back into the database. This will be true whether it's of a type that you can launch directly (like a PDF) or a type you have to download (like a JPG).
#3 Create a calculation that is "http://yourserver.com/yourpath/" & YEAR & "/" & Registration Number & ".pdf"
Then make that field the web address for a web viewer or open it in a new browser window using the Open URL script and button step
There are also ways the upload and the renaming of the file can be automated too... depending...
This is a big issue with asset [paper] management databases where clients still follow a document-based model; ie a document is a unique, unchangeable record and a PDF has become the de facto standard for digitising documents:
I have created a legal Paper-trail database including a script written in AutoIT (Windows) - http://www.autoitscript.com/site/autoit/ -which launches each affadavit or document in a legal case in a PDF viewer from within Filemaker - but as elegant as it can be made to look, it's a convoluted workaround for what really boils down to a an intellectual property issue.
Please, Filemaker, can you talk this over with Adobe?
Filemaker's inability to provide a PDF viewer is a hurdle for us developers - and a deal-breaker for lots of clients.