WD12 - BLOB MySQL

Le
I.G.LOG
Bonjour,

Je dois stocker des documents Word dans une base MySQL 4.1.9 (j'utilise
l'accès natif PCSoft)
Je n'ai encore jamais effectué ce genre de choses avec Windev.
J'ai fait des recherches sur le net mais je n'ai trouvé aucun début de
piste.
Quelle sont les fonctions SQL disponibles pour récupérer les rubriques de
type blob, les enregistrer etc

Merci
Vidéos High-Tech et Jeu Vidéo
Téléchargements
  • de Blob fait un peu plus parler de lui à travers cette nouvelle vidéo. L'occasion de ...
  • de Blob est un titre tout ce qu'il y a de plus original. Prévu pour septembre, il est ...
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Eric Demeester
Le #19586991
dans (in) fr.comp.developpement.agl.windev, "I.G.LOG" ecrivait (wrote) :

Bonjour,

Je dois stocker des documents Word dans une base MySQL 4.1.9 (j'utilise
l'accès natif PCSoft)
Quelle sont les fonctions SQL disponibles pour récupérer les rubriques de
type blob, les enregistrer etc...



A priori, il n'y a pas de fonctions SQL particulières pour lire ou
écrire des champs blob. Autrement dit, les ordres SQL classiques
(insert, alter, etc.) fonctionnenent avec les champs blob comme avec les
autres types de champs.

En ce qui me concerne, je préfère stocker les documents sous leur forme
originale et mettre un pointeur dans la base de données indiquant où ils
sont, (ça évite pas mal de problèmes d'encodage/décodage et ça permet de
les ranger logiquement -- répertoire word, répertoire pdf, répertoire
images, etc. --), mais c'est juste une opinion personnelle.

Merci



HTH.

--
Eric
I.G.LOG
Le #19587181
Bonjour

A priori, il n'y a pas de fonctions SQL particulières pour lire ou
écrire des champs blob. Autrement dit, les ordres SQL classiques
(insert, alter, etc.) fonctionnenent avec les champs blob comme avec les
autres types de champs.




si j'ai un document word sur le disque, comment faire un "insert into TABLE
(RUBBLOB) values (????)" ?
Pour ce qui est de la modif je pense qu'il suffit de lire la rubrique,
l'enregistrer sur le disque, et ensuite l'ouvrir sous Word. C'est bien ça ?
Mais comment l'écrire sur le disque ?

En ce qui me concerne, je préfère stocker les documents sous leur forme
originale et mettre un pointeur dans la base de données indiquant où ils
sont, (ça évite pas mal de problèmes d'encodage/décodage et ça permet de
les ranger logiquement -- répertoire word, répertoire pdf, répertoire
images, etc. --), mais c'est juste une opinion personnelle.




oui je pense que cette idée est plus intéressante en effet. Je vais
m'orienter là-dessus. Il reste à convaincre mon client qui demandait un
enregistrement dans la base !!

Encore merci
JeAn-PhI
Le #19591481
Après mûre réflexion, I.G.LOG a écrit :
Bonjour

A priori, il n'y a pas de fonctions SQL particulières pour lire ou
écrire des champs blob. Autrement dit, les ordres SQL classiques
(insert, alter, etc.) fonctionnenent avec les champs blob comme avec les
autres types de champs.




si j'ai un document word sur le disque, comment faire un "insert into TABLE
(RUBBLOB) values (????)" ?
Pour ce qui est de la modif je pense qu'il suffit de lire la rubrique,
l'enregistrer sur le disque, et ensuite l'ouvrir sous Word. C'est bien ça ?
Mais comment l'écrire sur le disque ?

En ce qui me concerne, je préfère stocker les documents sous leur forme
originale et mettre un pointeur dans la base de données indiquant où ils
sont, (ça évite pas mal de problèmes d'encodage/décodage et ça permet de
les ranger logiquement -- répertoire word, répertoire pdf, répertoire
images, etc. --), mais c'est juste une opinion personnelle.




oui je pense que cette idée est plus intéressante en effet. Je vais
m'orienter là-dessus. Il reste à convaincre mon client qui demandait un
enregistrement dans la base !!

Encore merci



passez par une variable de type texte et faire :
File est chaine = fchargetexte("c:file.doc")
puis
"insert into table set rub = '"+File+"'"

pour lire :
File est chaine
"select rub from table"
File = SQLLit...
fsauvetexte(File)

--
Cordialement JeAn-PhI
jacques Trepp
Le #19591401
"I.G.LOG" news:4a390884$0$17098$
Bonjour

A priori, il n'y a pas de fonctions SQL particulières pour lire ou
écrire des champs blob. Autrement dit, les ordres SQL classiques
(insert, alter, etc.) fonctionnenent avec les champs blob comme avec les
autres types de champs.




si j'ai un document word sur le disque, comment faire un "insert into
TABLE (RUBBLOB) values (????)" ?
Pour ce qui est de la modif je pense qu'il suffit de lire la rubrique,
l'enregistrer sur le disque, et ensuite l'ouvrir sous Word. C'est bien ça
? Mais comment l'écrire sur le disque ?

En ce qui me concerne, je préfère stocker les documents sous leur forme
originale et mettre un pointeur dans la base de données indiquant où ils
sont, (ça évite pas mal de problèmes d'encodage/décodage et ça permet de
les ranger logiquement -- répertoire word, répertoire pdf, répertoire
images, etc. --), mais c'est juste une opinion personnelle.




oui je pense que cette idée est plus intéressante en effet. Je vais
m'orienter là-dessus. Il reste à convaincre mon client qui demandait un
enregistrement dans la base !!

Encore merci




Bonjour,

penser également aux dump qui risquent d'exploser avec les images stockées
dans la base...

cdlt

--
Jacques TREPP
Albypam
3, rue Jean Mermoz
81160 - ST Juery


__________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4165 (20090618) __________

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com
I.G.LOG
Le #19591611
>
passez par une variable de type texte et faire :
File est chaine = fchargetexte("c:file.doc")
puis
"insert into table set rub = '"+File+"'"

pour lire :
File est chaine
"select rub from table"
File = SQLLit...
fsauvetexte(File)




Bonjour,
Merci pour cette réponse qui va me permettre d'avancer.
Bon dev,
Phil
I.G.LOG
Le #19591601
>
penser également aux dump qui risquent d'exploser avec les images stockées
dans la base...

cdlt




Bonjour,
Oui, pour ces raisons, je vais plutot m'orienter vers cette solution
Enocre merci
Gilles
Le #19591591
I.G.LOG avait énoncé :
Bonjour,

Je dois stocker des documents Word dans une base MySQL 4.1.9 (j'utilise
l'accès natif PCSoft)
Je n'ai encore jamais effectué ce genre de choses avec Windev.
J'ai fait des recherches sur le net mais je n'ai trouvé aucun début de piste.
Quelle sont les fonctions SQL disponibles pour récupérer les rubriques de
type blob, les enregistrer etc...



Regarde HattacheMemo et HextraitMemo.
C'est ça que j'utilisais quand je faisais ce genre de choses.

Utiliser le filesystem, c'est s'obliger à être dépendant d'un chemin de
serveur qui change, d'un partage qui change, d'un tas de bêtises de ce
genre...
Et en plus de devoir faire 2 backups.

A moins que tes documents ne soient ultra volumineux, les mettre en
base, c'est l'assurance de pouvoir lire la donnée de n'importe où, même
à distance, sans aucun accès au filesystem.
I.G.LOG
Le #19592511
>
Regarde HattacheMemo et HextraitMemo.
C'est ça que j'utilisais quand je faisais ce genre de choses.

Utiliser le filesystem, c'est s'obliger à être dépendant d'un chemin de
serveur qui change, d'un partage qui change, d'un tas de bêtises de ce
genre...
Et en plus de devoir faire 2 backups.

A moins que tes documents ne soient ultra volumineux, les mettre en base,
c'est l'assurance de pouvoir lire la donnée de n'importe où, même à
distance, sans aucun accès au filesystem.





Bonjour
C'est en effet ce que je pensais. Mais dans chaque solution il y a avantages
et inconvénients.
Comme le dit Eric, il risque d'y avoir des problèmes d'encodage/décodage,
non ?

Merci
Daniel
Le #19593051
I.G.LOG a écrit :
Regarde HattacheMemo et HextraitMemo.
C'est ça que j'utilisais quand je faisais ce genre de choses.

Utiliser le filesystem, c'est s'obliger à être dépendant d'un chemin de
serveur qui change, d'un partage qui change, d'un tas de bêtises de ce
genre...
Et en plus de devoir faire 2 backups.

A moins que tes documents ne soient ultra volumineux, les mettre en base,
c'est l'assurance de pouvoir lire la donnée de n'importe où, même à
distance, sans aucun accès au filesystem.





Bonjour
C'est en effet ce que je pensais. Mais dans chaque solution il y a avantages
et inconvénients.
Comme le dit Eric, il risque d'y avoir des problèmes d'encodage/décodage,
non ?

Merci





Tout dépend du besoin.

Si c'est pour gérer quelques documents, c'est bien plus simple à insérer
dans un champs type Blob. Si c'est pour gérer de nombreux documents du
type GED je pense qu'il est préférable de le faire à un autre niveau que
la base.

Le premier cas est plus simple à mettre en place, mais peu efficace. Le
second cas est plus difficile à mettre en place, mais bien plus efficace
en terme de maintenance, de charge, d'évolution et de sauvegarde.

Pour la seconde solution WebDAV est une des solutions clé en main qui
permettent de le faire.

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Gilles
Le #19593411
I.G.LOG avait énoncé :

Regarde HattacheMemo et HextraitMemo.
C'est ça que j'utilisais quand je faisais ce genre de choses.

Utiliser le filesystem, c'est s'obliger à être dépendant d'un chemin de
serveur qui change, d'un partage qui change, d'un tas de bêtises de ce
genre...
Et en plus de devoir faire 2 backups.

A moins que tes documents ne soient ultra volumineux, les mettre en base,
c'est l'assurance de pouvoir lire la donnée de n'importe où, même à
distance, sans aucun accès au filesystem.





Bonjour
C'est en effet ce que je pensais. Mais dans chaque solution il y a avantages
et inconvénients.
Comme le dit Eric, il risque d'y avoir des problèmes d'encodage/décodage, non
?



Bennn?? non?
Un fichier, jusqu'à preuve du contraire, c'est une suite d'octets.
Quand tu le mets en base, aucun bit n'est modifié.

Et quand tu le récupères non plus.
Publicité
Poster une réponse
Anonyme