Brug af BLOB-type kolonne i Oracle APEX

Lagring og adgang til vedhæftede filer i BLOB-datatyper gennem Oracle APEX

Her er skemadesignet for den tabel, jeg brugte, som indeholder en BLOB-type datakolonne. Bemærk:dette vil ikke være designet af den endelige løsning; følg blot med ændringerne, efterhånden som de kommer, så du kan forstå, hvad jeg fandt ud af om nogle få begrænsninger af APEX-formular- og rapportoprettelsesguiderne.

Første forsøg:Opsætning af APEX-tabellen, formularen og rapporten

Tabel:MY_DOC_STACK Første layoutforsøg

Kolonnen DOC_FILE er BLOB-typen, som gemmer selve dokumentvedhæftningen. Dette er udseendet af formularen og rapporten, der er oprettet ved hjælp af APEX-applikationsguiden, som peger direkte på tabellen:

TILFØJELSE AF ET DOKUMENT til det BLOB-typede felt

Rapportforespørgslen ser ud til at fungere som vist nedenfor:

Her er en liste over flere poster med vedhæftede dokumenter:

Eksempelrapportoutput med flere poster

Problemet er, når du forsøger at downloade filen, der blev lagt i BLOB-feltet:

Det er subtilt fra billedet, men den identificerede mime-type:Application/Octet-Stream er en indikator på, at APEX-formularen har mistet overblikket over den type fil (Microsoft Word, docx), som jeg lige havde uploadet. Den gemte fil er kun en masse skraldtegn. At prøve at ændre filtypenavnet hjælper heller ikke.

Andet (revideret) forsøg:justeringer af APEX-applikationsdesign til blob-/dokumenthåndtering

Selvom applikationsområderne og deres komponenter ikke virkede umiddelbart efter, at guiden var fuldført, er der kun et par mindre redigeringer for at sætte den i funktionsdygtig stand. Nærmere inspektion af formularelementet PX_DOC_FILE viser, at BLOB-formularelementer kræver nogle ekstra metaoplysninger om den fil, der er knyttet til posten:

Jeg gik videre og definerede de yderligere kolonner og føjede den til den BLOB-holdige tabel (MY_DOC_STACK), den uploadende Apex-formular og rapportregionsdefinitionen.

Bemærk, at kolonnenavnene (for overskuelighedens skyld) er blevet gjort de samme som kravene til Blob-formularelementet DOC_FILE .

Revideret Apex-formular til dokumentvedhæftning

Jeg troede oprindeligt, at man skulle være klog for at forudse alle mulige værdier af Mime Types (msword, pdf, zip osv.), men det var unødvendigt. Ligeledes for de andre felter, der er reserveret til tegntype, og sidst opdaterede kolonner.

Revideret rapport om upload af dokumentblob

Revideret rapportoutputdiskussion

1. [Ejer:AUDREY HEPBURN]:Jeg tvang MIME_TYPE med min formular til "Applikation/msword"; Selvom den fil, jeg uploadede, var af typen ".docx", blev den gemt til min lokale klient som et ".doc"-format (det gamle MS Word-format) ved at downloade den tilbage gennem Apex-siden.

2. [Ejer:CHEVY CHASE]:Denne gang, MIME_TYPE blev ikke indtastet, og Apex-formularprocessen/-handlingen føjede dette til posten, da den blev oprettet:

   application/vnd.openxmlformats-officedocument.wordprocessingml.document

   Dette er sandsynligvis det format, der er angivet af Microsoft Office 2013 . FILE_NAME værdien var brugerdefineret, og .docx-udvidelsen blev tilføjet eksplicit. Resultatet var, at download af filen fik brugeren til at åbne filen ved at bruge det korrekte program på min klientcomputer:MS Word (version 2013).

3. [Ejer:CARRIE FISHER]:Samme som testcase (2), men ved at bruge en Adobe PDF (Portable Document Format) i stedet. Samme adfærd undtagen MIME_TYPE identificerede sig selv som applikation/pdf; fil åbnet som forventet.

Flere diskussion:

Alle disse problemer er fra de generiske DML API'er, som Apex bruger til at administrere indsættelser, opdateringer og sletninger fra applikationens skema, højst sandsynligt er det en del af Apex's hærdning mod SQL-injektionsangreb. Den direkte INSERT og SELECT sætninger, der bruges i din SQL-klient, er ikke den samme måde, som et standardformulardesign (fra en applikationsguide) er sat op til at administrere DML-transaktioner.

Bemærk, at sideprocessen:Process Row of MY_DOC_STACK ser mere parameterdrevet ud. Hvis der er en DML-operation derinde et eller andet sted, vil den først blive baseret på den omhyggelige screening af hver inputvariabel, der indsendes via Apex-formularen.

Der er mange andre måder, Apex kan administrere DML-transaktioner på; ... denne løsning fokuserer på, hvad der højst sandsynligt er stødt på af OP.

Held og lykke!