Export PDF Field Content Does Not Work

I have a WebDirect solution that has a layout that displays a portal of file records. Each file record has a container field that holds the file. A user can click on a portal row to display a popover with an enlarged version of the container field. The container field does not display interactive PDFs because files are automatically imported into the container field as files, not as PDF files (there are other file types as well). A button on the popover allows the user to download the file.

A problem occurs when users attempt to download PDF files. PDF files, and only PDF files, are corrupted when downloaded via WebDirect. This behaviour is consistent on Mac OS and Windows. This behaviour is non-existant when using FileMaker Pro. This behaviour is non existant with other file types.

Anyone have a clue as to how I could solve this issue?

What are the steps you're taking to download the file? Can you check on the file type and use some of the container functions and data file functions to write the field contents out differently?

Let me give you as much information as possible.

The layout contains a portal that points to a File table. The portal row contains a popover button. The popover contains a calculation field (result type is container) and a button. The container field is accessible in browse mode. The container field is optimized for interactive content. The button executes one script step: export field content, with the field pre-selected and the file name undefined. Create folders is set to no.

Users click on the popover button to view an enlarged version of a file (if it is viewable on screen) or to download a file. Users click on the download button or right-click on the calculated container field
to download the file.

Interactive content is not interactive in FileMaker Pro or WebDirect, even if they are PDFs. I believe this has to do with the way files were inserted in the container field of the File table. The File table is populated automatically via a synchronization script. Each record hold only one file. The file type varies from record to record. The synchronization step uses "insert file" to insert a file into a record, therefore FileMaker is unaware of the inserted file type (PDF, image, audio/video, other).

Could I rewrite the synchronization process so that it analyzes the file name prior to import, and then insert using "insert PDF", "Insert Image", etc. instead of using "Insert File"? Sureā€¦ but I need to do my due diligence before I ask a customer to pay for a change instead of a fix.

You've verified that the error is on export and not on the process of storing the PDF? In other words you can export the same PDF files from a FileMaker Pro client and they're intact and download as files that can be opened and read etc?

And.. from a webdirect browser session, is it that it downloads a file but the file is corrupted and won't open? As opposed to erroring out and refusing to download any file whatsoever?

As mentioned in the original post, this behaviour is non-existant in FileMaker Pro or with other file types. Therefore, in answer to your question more directly, PDF files export without issue in FileMaker Pro. They also download when using WebDirect without error, at least none reported by browsers.

I did notice, however, that download stalls in the end of downloading PDF files. That is, download proceeds normally, then download speed slows down considerably over the course of about one minute, then ends without browser error. The downloaded PDF file has the expected size on the computer. Double-clicking the downloaded PDF file produces an error by whatever application is responsible to open PDF files.

what other file types did work?
JPEG, PNG, usual graphic stuff or also office docs etc.
my guess would be WD getting the mime type of the PDF file wrong at a certain point?

I personally downloaded PNG, JPEG, BMP and Excel files without issue. Is there any way of "fixing" WebDirect if the file's mime type is wrong?

I wrote this more in the sense of "hm, could be this reason, maybe I'd look, if somebody else had the same error" and not so much because I have a solution at hand :frowning_face:

that's just because I remember having had problems while doing web design in the good old days [TM]