Gebruik van BLOB-type kolom in Oracle APEX

Bestandsbijlagen in BLOB-gegevenstypen opslaan en openen via Oracle APEX

Hier is het schemaontwerp voor de tabel die ik heb gebruikt en die een BLOB-getypte gegevenskolom bevat. Let op:dit zal niet het ontwerp van de uiteindelijke oplossing zijn; volg gewoon de wijzigingen zoals ze komen, zodat u kunt begrijpen wat ik heb ontdekt over een paar beperkingen van de APEX-wizards voor het maken van formulieren en rapporten.

Eerste poging:de APEX-tabel, het formulier en het rapport instellen

Tabel:MY_DOC_STACK Eerste poging tot lay-out

De kolom DOC_FILE is het BLOB-type dat de daadwerkelijke documentbijlage opslaat. Dit is het uiterlijk van het formulier en het rapport dat is gemaakt met behulp van de APEX-toepassingswizard die rechtstreeks naar de tabel verwijst:

EEN DOCUMENT TOEVOEGEN aan het BLOB-getypte veld

De rapportquery lijkt te werken zoals hieronder weergegeven:

Hier is een lijst met meer records met documentbijlagen:

Voorbeeldrapportuitvoer met meerdere records

Het probleem is wanneer u het bestand probeert te downloaden dat in het BLOB-veld is geplaatst:

Het is subtiel op de foto, maar het geïdentificeerde mime-type:Application/Octet-Stream is een indicator dat het APEX-formulier het type bestand (Microsoft Word, docx) dat ik zojuist had geüpload uit het oog is verloren. Het opgeslagen bestand is slechts een stelletje afvaltekens. De bestandsextensie proberen te veranderen helpt ook niet.

Tweede (herziene) poging:aanpassingen aan APEX-toepassingsontwerp voor Blob/Document Handling

Hoewel de toepassingsgebieden en hun componenten niet onmiddellijk werkten nadat de wizard was voltooid, zijn er slechts een paar kleine bewerkingen om het in werkende staat te brengen. Nadere inspectie van het formulierelement PX_DOC_FILE laat zien dat BLOB-formulierelementen wat aanvullende meta-informatie nodig hebben over het bestand dat aan het record is toegevoegd:

Ik ging door en definieerde de extra kolommen en voegde deze toe aan de BLOB-bevattende tabel (MY_DOC_STACK), het upload-Apex-formulier en de rapportregiodefinitie.

Merk op dat de kolomnamen (voor de eenvoud) hetzelfde zijn gemaakt als de vereisten van het Blob-formulierelement DOC_FILE .

Herzien apex-formulier voor documentbijlagen

Ik dacht eerst dat je slim moest zijn om te anticiperen op alle mogelijke waarden van Mime Types (msword, pdf, zip, etc.) maar dat was niet nodig. Hetzelfde geldt voor de andere velden die zijn gereserveerd voor het type teken en de laatst bijgewerkte kolommen.

Herzien document-blob-uploadrapport

Bespreking herziene rapportuitvoer

1. [Eigenaar:AUDREY HEPBURN]:Ik heb de MIME_TYPE geforceerd met mijn formulier naar "Applicatie/msword"; hoewel het bestand dat ik heb geüpload van het type ".docx" was, werd het door het terug te downloaden via de Apex-pagina op mijn lokale client opgeslagen als een ".doc"-formaat (het oude MS Word-formaat).

2. [Eigenaar:CHEVY CHASE]:Deze keer MIME_TYPE is niet ingevoerd en het Apex-formulierproces/-actie heeft dit aan het record toegevoegd toen het werd gemaakt:

   application/vnd.openxmlformats-officedocument.wordprocessingml.document

   Dit is waarschijnlijk het formaat dat is aangewezen door Microsoft Office 2013 . De FILE_NAME waarde is door de gebruiker gedefinieerd en de .docx-extensie is expliciet toegevoegd. Het resultaat was dat bij het downloaden van het bestand de gebruiker het bestand standaard moest openen met de juiste toepassing op mijn clientcomputer:MS Word (versie 2013).

3. [Eigenaar:CARRIE FISHER]:Hetzelfde als testcase (2) maar in plaats daarvan met een Adobe PDF (Portable Document Format). Hetzelfde gedrag behalve de MIME_TYPE identificeerde zichzelf als applicatie/pdf; bestand geopend zoals verwacht.

Meer discussie:

Al deze problemen komen van de generieke DML API's die Apex gebruikt om invoegingen, updates en verwijderingen uit het schema van de applicatie te beheren, hoogstwaarschijnlijk maakt het deel uit van Apex's verharding tegen SQL-injectieaanvallen. De directe INSERT en SELECT instructies die in uw SQL-client worden gebruikt, is niet dezelfde manier waarop een standaardformulierontwerp (van een toepassingswizard) is ingesteld om DML-transacties te beheren.

Merk op dat het paginaproces:Process Row of MY_DOC_STACK ziet er meer parametergestuurd uit. Als er ergens een DML-bewerking is, wordt deze eerst gebaseerd op een zorgvuldige screening van elke invoervariabele die via het Apex-formulier wordt ingediend.

Er zijn veel andere manieren waarop Apex DML-transacties kan beheren; ... deze oplossing richt zich op wat de OP het meest waarschijnlijk is tegengekomen.

Veel succes!