Here is the schema design for the table I used which contains a BLOB typed data column. Note: this will not be the design of the final solution; just follow with the changes as they come so that you can understand what I found out about a few limitations of the APEX Form and Report creation wizards.
The column DOC_FILE is the BLOB type which stores the actual document attachment. This is the look of the Form and the Report created using the APEX Application wizard which points directly to the table:
ADDING a DOCUMENT to the BLOB Typed Field
The report query seems to work as shown below:
Here is a list of more records with document attachments:
The problem is when trying to download the file that was put into the BLOB field:
It's subtle from the picture, but the identified mime type: Application/Octet-Stream is an indicator that the APEX form has lost track of the type of file (Microsoft Word, docx) that I had just uploaded. The file saved is just a bunch of garbage characters. Trying to change the file extension doesn't help either.
Although the application regions and their components did not work immediately after the wizard completed, there are only a few minor edits to put it into working condition. Closer inspection of the form element PX_DOC_FILE shows that BLOB form elements require some additional meta-information about the file attached to the record:
I went ahead and defined the additional columns and added it to the BLOB-containing table (MY_DOC_STACK), the uploading Apex form and the report region definition.
Note that the column names (for simplicity) have been made the same as the requirements of the Blob form element DOC_FILE.
I initially thought one had to be clever to anticipate all the possible values of Mime Types (msword, pdf, zip, etc.) but that was unnecessary. Likewise for the other fields reserved for character type, and last updated columns.
IMPORTANT NOTE: You can actually skip form inputs for the supporting Blob meta-data fields. Values such as MIME_TYPE and CHARACTER_TYPE are automatically detected when the document attachment is uploaded. The Apex form ITEM storing the document blob just needs the names of the columns that will store this information.
ADDITIONAL NOTE: After adding the new columns, expanding the form and report column references, you will need to clear (or truncate) the existing table or reload each document attachment to be sure. You may be able to still use the uploads from the first attempts, but you'll need to verify that for yourself to be sure.
[Owner: AUDREY HEPBURN]: I forced the MIME_TYPE with my form to "Application/msword"; although the file I uploaded was ".docx" type, downloading it back through the Apex page saved it to my local client as a ".doc" format (the old MS Word format).
[Owner: CHEVY CHASE]: This time, MIME_TYPE was not inputted and the Apex form process/action added this to the record when it was created:
This probably is the format designated by Microsoft Office 2013. The FILE_NAME value was user defined and the .docx extension was added explicitly. The result was that downloading the file prompted the user defaulted to open up the file using the correct application on my client computer: MS Word (Version 2013).
[Owner: CARRIE FISHER]: Same as test case (2) but using an Adobe PDF (Portable Document Format) Instead. Same behavior except the MIME_TYPE identified itself as application/pdf; file opened as expected.
All this trouble is from the the generic DML API's that Apex uses to manage inserts, updates and deletes from the application's schema, most likely it is part of Apex's hardening against SQL injection attacks. The direct INSERT and SELECT statements used in your SQL client is not the same way that a default form design (from an application wizard) is set up to manage DML transactions.
Note that the page process: Process Row of MY_DOC_STACK looks more parameter driven. If there is a DML operation in there somewhere, it will be based first on the careful screening of each input variable submitted through the Apex form.
There are many other ways that Apex can manage DML transactions; ... this solution focuses on what was most likely encountered by the OP.