Use of BLOB type column in Oracle APEX

后端 未结 1 561
一向
一向 2020-12-10 21:53

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

相关标签:
1条回答
  • 2020-12-10 22:39

    Storing and Accessing File Attachments in BLOB Data Types Through Oracle APEX

    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.

    First Attempt: Setting Up the APEX Table, Form and Report

    Table: MY_DOC_STACK First Layout Attempt

    Table MY_DOC_STACK Layout One

    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

    How to Add a Document to the BLOB Column

    The report query seems to work as shown below:

    Confirmed Document Attachment to BLOB Field

    Here is a list of more records with document attachments:

    Sample Report Output With Multiple Records

    Sample Report Output With Multiple Records

    The problem is when trying to download the file that was put into the BLOB field:

    Downloading Document Attachment from the BLOB

    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.

    Second (Revised) Attempt: Adjustments to APEX Application Design for Blob/Document Handling

    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:

    <code>DOC_FILE</code> Blob Field Definition

    What's missing from the blob field Form input item:

    1. Mime Type
    2. File Name
    3. Character Set
    4. 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.

    MY_DOC_STACK Table Revised Layout

    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

    Revised Document Attachment 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 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.

    Revised Document Blob Upload Report

    Revised Blob Table Report

    Revised Report Output Discussion

    1. [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).

    2. [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).

    3. [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.

    Form Process Row DML

    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!

    0 讨论(0)
提交回复
热议问题