Oracle
 sql >> Base de données >  >> RDS >> Oracle

Utilisation de la colonne de type BLOB dans Oracle APEX

Stockage et accès aux pièces jointes dans les types de données BLOB via Oracle APEX

Voici la conception de schéma pour la table que j'ai utilisée qui contient une colonne de données de type BLOB. Remarque :ce ne sera pas la conception de la solution finale ; suivez simplement les changements au fur et à mesure qu'ils surviennent afin que vous puissiez comprendre ce que j'ai découvert sur quelques limitations des assistants de création de formulaires et de rapports APEX.

Première tentative :configuration du tableau, du formulaire et du rapport APEX

Table :MY_DOC_STACK Première tentative de mise en page

La colonne DOC_FILE est le type BLOB qui stocke la pièce jointe réelle du document. Voici l'apparence du formulaire et du rapport créés à l'aide de l'assistant d'application APEX qui pointe directement vers le tableau :

AJOUTER un DOCUMENT au champ typé BLOB

La requête de rapport semble fonctionner comme indiqué ci-dessous :

Voici une liste d'autres enregistrements avec pièces jointes :

Exemple de sortie de rapport avec plusieurs enregistrements

Le problème survient lorsque vous essayez de télécharger le fichier qui a été placé dans le champ BLOB :

C'est subtil à partir de l'image, mais le type MIME identifié :Application/Octet-Stream est un indicateur que le formulaire APEX a perdu la trace du type de fichier (Microsoft Word, docx) que je venais de télécharger. Le fichier enregistré est juste un tas de caractères inutiles. Essayer de changer l'extension du fichier n'aide pas non plus.

Deuxième tentative (révisée) :ajustements de la conception de l'application APEX pour la gestion des objets blob/documents

Bien que les régions d'application et leurs composants n'aient pas fonctionné immédiatement après la fin de l'assistant, il n'y a que quelques modifications mineures pour le mettre en état de fonctionnement. Examen plus approfondi de l'élément de formulaire PX_DOC_FILE montre que les éléments de formulaire BLOB nécessitent des méta-informations supplémentaires sur le fichier joint à l'enregistrement :

Je suis allé de l'avant et j'ai défini les colonnes supplémentaires et je les ai ajoutées à la table contenant le BLOB (MY_DOC_STACK), au formulaire Apex de téléchargement et à la définition de la région du rapport.

Notez que les noms de colonne (pour plus de simplicité) ont été rendus identiques aux exigences de l'élément de formulaire Blob DOC_FILE .

Formulaire Apex révisé de pièce jointe

J'ai d'abord pensé qu'il fallait être malin pour anticiper toutes les valeurs possibles des Types Mime (msword, pdf, zip, etc.) mais ce n'était pas nécessaire. De même pour les autres champs réservés au type caractère, et dernières colonnes mises à jour.

Rapport révisé de téléchargement de blob de documents

Discussion sur les résultats du rapport révisé

  1. [Propriétaire :AUDREY HEPBURN] :J'ai forcé le MIME_TYPE avec mon formulaire à "Application/msword" ; bien que le fichier que j'ai téléchargé soit de type ".docx", le télécharger via la page Apex l'a enregistré sur mon client local au format ".doc" (l'ancien format MS Word).

  2. [Propriétaire :CHEVY CHASE] :Cette fois, MIME_TYPE n'a pas été saisi et le processus/l'action du formulaire Apex a ajouté ceci à l'enregistrement lors de sa création :

    application/vnd.openxmlformats-officedocument.wordprocessingml.document

    C'est probablement le format désigné par Microsoft Office 2013 . Le FILE_NAME la valeur a été définie par l'utilisateur et l'extension .docx a été ajoutée explicitement. Le résultat a été que le téléchargement du fichier a incité l'utilisateur à ouvrir le fichier par défaut à l'aide de l'application appropriée sur mon ordinateur client :MS Word (version 2013).

  3. [Propriétaire :CARRIE FISHER] :Identique au cas de test (2) mais en utilisant un Adobe PDF (Portable Document Format) à la place. Même comportement sauf le MIME_TYPE s'est identifié comme application/pdf ; fichier ouvert comme prévu.

Plus de discussions :

Tous ces problèmes proviennent des API DML génériques qu'Apex utilise pour gérer les insertions, les mises à jour et les suppressions du schéma de l'application. Cela fait très probablement partie du renforcement d'Apex contre les attaques par injection SQL. Le INSERT direct et SELECT instructions utilisées dans votre client SQL n'est pas la même qu'une conception de formulaire par défaut (à partir d'un assistant d'application) est configurée pour gérer les transactions DML.

Notez que le traitement de la page :Process Row of MY_DOC_STACK semble plus axé sur les paramètres. S'il existe une opération DML quelque part, elle sera d'abord basée sur le filtrage minutieux de chaque variable d'entrée soumise via le formulaire Apex.

Il existe de nombreuses autres façons pour Apex de gérer les transactions DML ; ... cette solution se concentre sur ce qui a été le plus probablement rencontré par le PO.

Bonne chance !