Användning av kolumn av BLOB-typ i Oracle APEX

Lagra och komma åt filbilagor i BLOB-datatyper via Oracle APEX

Här är schemadesignen för tabellen jag använde som innehåller en BLOB-typad datakolumn. Notera:detta kommer inte att vara utformningen av den slutliga lösningen; följ bara med ändringarna när de kommer så att du kan förstå vad jag fick reda på om några begränsningar i APEX-formuläret och guiderna för att skapa rapporter.

Första försöket:Konfigurera APEX-tabellen, formuläret och rapporten

Tabell:MY_DOC_STACK Första layoutförsök

Kolumnen DOC_FILE är BLOB-typen som lagrar själva dokumentbilagan. Så här ser formuläret och rapporten skapade med hjälp av APEX-programguiden som pekar direkt till tabellen:

LÄGG TILL ett DOKUMENT i det BLOB-skrivna fältet

Rapportfrågan verkar fungera enligt nedan:

Här är en lista över fler poster med dokumentbilagor:

Provrapportutdata med flera poster

Problemet är när man försöker ladda ner filen som placerades i BLOB-fältet:

Det är subtilt från bilden, men den identifierade mimetypen:Application/Octet-Stream är en indikator på att APEX-formuläret har tappat reda på vilken typ av fil (Microsoft Word, docx) som jag precis hade laddat upp. Den sparade filen är bara ett gäng skräptecken. Att försöka ändra filtillägget hjälper inte heller.

Andra (reviderat) försöket:justeringar av APEX-applikationsdesign för blob-/dokumenthantering

Även om applikationsregionerna och deras komponenter inte fungerade omedelbart efter att guiden slutförts, finns det bara några få mindre ändringar för att sätta den i fungerande skick. Närmare granskning av formulärelementet PX_DOC_FILE visar att BLOB-formulärelement kräver ytterligare metainformation om filen som är bifogad till posten:

Jag gick vidare och definierade de ytterligare kolumnerna och la till den i tabellen som innehåller BLOB (MY_DOC_STACK), formuläret för uppladdning av Apex och definitionen av rapportregionen.

Observera att kolumnnamnen (för enkelhetens skull) har gjorts samma som kraven för Blob-formulärelementet DOC_FILE .

Reviderat Apex-formulär för dokumentbilaga

Jag trodde först att man måste vara smart för att förutse alla möjliga värden för Mime Types (msword, pdf, zip, etc.) men det var onödigt. Likaså för de andra fälten reserverade för teckentyp och senast uppdaterade kolumner.

Reviderad rapport för uppladdning av dokumentblobb

Reviderad rapportutdatadiskussion

1. [Ägare:AUDREY HEPBURN]:Jag tvingade fram MIME_TYPE med mitt formulär till "Application/msword"; även om filen jag laddade upp var ".docx"-typ, sparades den till min lokala klient som ett ".doc"-format (det gamla MS Word-formatet) när jag laddade ner den via Apex-sidan.

2. [Ägare:CHEVY CHASE]:Den här gången MIME_TYPE matades inte in och Apex-formulärprocessen/åtgärden lade till detta i posten när den skapades:

   application/vnd.openxmlformats-officedocument.wordprocessingml.document

   Detta är förmodligen formatet som anges av Microsoft Office 2013 . FILE_NAME värde var användardefinierat och tillägget .docx lades till explicit. Resultatet var att nedladdningen av filen uppmanade användaren att öppna filen med rätt applikation på min klientdator:MS Word (version 2013).

3. [Ägare:CARRIE FISHER]:Samma som testfall (2) men med en Adobe PDF (Portable Document Format) istället. Samma beteende förutom MIME_TYPE identifierade sig som applikation/pdf; filen öppnas som förväntat.

Mer diskussion:

Allt detta problem kommer från de generiska DML API:erna som Apex använder för att hantera infogningar, uppdateringar och borttagningar från programmets schema, troligen är det en del av Apex härdning mot SQL-injektionsattacker. Den direkta INSERT och SELECT satser som används i din SQL-klient är inte på samma sätt som en standardformulärdesign (från en applikationsguide) är inställd för att hantera DML-transaktioner.

Observera att sidprocessen:Process Row of MY_DOC_STACK ser mer parameterstyrd ut. Om det finns en DML-operation där någonstans, kommer den att baseras först på den noggranna genomgången av varje indatavariabel som skickas in via Apex-formuläret.

Det finns många andra sätt som Apex kan hantera DML-transaktioner på; ... den här lösningen fokuserar på det som med största sannolikhet möttes av OP.

Lycka till!