Oracle
 sql >> база данни >  >> RDS >> Oracle

Използване на колона тип BLOB в Oracle APEX

Съхраняване и достъп до прикачени файлове в BLOB типове данни чрез Oracle APEX

Ето дизайна на схемата за таблицата, която използвах, която съдържа BLOB въведена колона с данни. Забележка:това няма да бъде дизайнът на крайното решение; просто следвайте промените, когато идват, за да можете да разберете какво разбрах за няколко ограничения на съветниците за създаване на формуляр и отчет на APEX.

Първи опит:Настройване на APEX таблица, формуляр и отчет

Таблица:MY_DOC_STACK Първи опит за оформление

Колоната DOC_FILE е типът BLOB, който съхранява действителния прикачен документ. Това е изгледът на формуляра и отчета, създаден с помощта на съветника за приложение APEX, който сочи директно към таблицата:

ДОБАВЯНЕ НА ДОКУМЕНТ към въведеното поле BLOB

Заявката за отчет изглежда работи, както е показано по-долу:

Ето списък с още записи с прикачени документи:

Примерен изходен отчет с множество записи

Проблемът е, когато се опитвате да изтеглите файла, който е поставен в полето BLOB:

Това е едва доловимо от снимката, но идентифицираният мим тип:Application/Octet-Stream е индикатор, че формулярът APEX е изгубил представа за типа на файла (Microsoft Word, docx), който току-що бях качил. Запазеният файл е просто куп боклук. Опитът да промените разширението на файла също не помага.

Втори (ревизиран) опит:Корекции в дизайна на приложението APEX за обработка на Blob/документ

Въпреки че регионите на приложението и техните компоненти не заработиха веднага след завършването на съветника, има само няколко незначителни редакции, за да го приведете в работно състояние. По-внимателна проверка на елемента на формуляра PX_DOC_FILE показва, че елементите на BLOB форма изискват допълнителна мета-информация за файла, прикачен към записа:

Продължих и дефинирах допълнителните колони и ги добавих към таблицата, съдържаща BLOB (MY_DOC_STACK), формуляра Apex за качване и дефиницията на региона на отчета.

Обърнете внимание, че имената на колоните (за простота) са направени същите като изискванията на елемента на Blob формуляр DOC_FILE .

Ревизиран апекс формуляр за прикачен документ

Първоначално мислех, че човек трябва да бъде умен, за да предвиди всички възможни стойности на Mime типове (msword, pdf, zip и т.н.), но това беше излишно. По същия начин за другите полета, запазени за тип символ и последно актуализирани колони.

Ревизиран отчет за качване на blob документ

Ревизирана дискусия за резултатите от отчета

  1. [Собственик:AUDREY HEPBURN]:Наложих MIME_TYPE с моя формуляр към „Приложение/msword“; въпреки че файлът, който качих, беше тип ".docx", изтеглянето му обратно през страницата Apex го записа в моя локален клиент като формат ".doc" (старият формат на MS Word).

  2. [Собственик:CHEVY CHASE]:Този път, MIME_TYPE не е въведен и процесът/действието на Apex формуляра добави това към записа, когато беше създаден:

    application/vnd.openxmlformats-officedocument.wordprocessingml.document

    Това вероятно е форматът, определен от Microsoft Office 2013 . FILE_NAME стойността е дефинирана от потребителя и разширението .docx е добавено изрично. Резултатът беше, че изтеглянето на файла подкани потребителя по подразбиране да отвори файла с помощта на правилното приложение на моя клиентски компютър:MS Word (версия 2013).

  3. [Собственик:КАРИ ФИШЪР]:Същото като тестов случай (2), но вместо това се използва Adobe PDF (формат за преносим документ). Същото поведение с изключение на MIME_TYPE идентифицира се като приложение/pdf; файлът се отвори според очакванията.

Още дискусии:

Всички тези проблеми са от генеричните DML API, които Apex използва за управление на вмъквания, актуализации и изтривания от схемата на приложението, най-вероятно това е част от втвърдяването на Apex срещу атаки чрез SQL инжектиране. Директният INSERT и SELECT изрази, използвани във вашия SQL клиент, не е по същия начин, по който дизайнът на формуляр по подразбиране (от съветник за приложение) е настроен за управление на DML транзакции.

Имайте предвид, че процесът на страницата:Process Row of MY_DOC_STACK изглежда повече задвижван от параметри. Ако там някъде има DML операция, тя първо ще се основава на внимателния преглед на всяка входна променлива, подадена чрез формуляра Apex.

Има много други начини, по които Apex може да управлява DML транзакции; ... това решение се фокусира върху това, което най-вероятно е срещнало OP.

Успех!




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Потребителско дефинирана рутина с DBMS_STATS, част II

  2. SQL/Regex предизвикателство/пъзел:Как да премахнете коментари от SQL код (чрез използване на SQL заявка)?

  3. Oracle:LONG или CLOB?

  4. OleDB Доставчик на данни не може да бъде намерен VBA/Excel

  5. Метод за събиране:EXISTS Функция в базата данни на Oracle