I am using a table having a BLOB column used to store a user\'s resume (it can be a word document, a pdf file or any other binary format).
Now in Oracle Apex 4.2, wh
This solution was also performed on an Apex 4.2 release (specifically, 4.2.5); Special thanks to the Oracle Corp for hosting my test instance at: http://apex.oracle.com.
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.
Table: MY_DOC_STACK First Layout Attempt
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:
Sample Report Output With Multiple Records
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:
What's missing from the blob field Form input item:
- Mime Type
- File Name
- Character Set
- BLOB Last Updated (date) Column
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
.
Revised Document Attachment Apex Form
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
andCHARACTER_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.
Revised Document Blob Upload Report
[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:
application/vnd.openxmlformats-officedocument.wordprocessingml.document
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.
More Discussion:
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.
Good Luck!