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...
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
dans (in) fr.comp.developpement.agl.windev, "I.G.LOG" <iglog@free.fr>
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.
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
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
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 !!
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
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
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)
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
"I.G.LOG" a écrit dans le message de 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" <iglog@free.fr> a écrit dans le message de
news:4a390884$0$17098$ba4acef3@news.orange.fr...
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.
"I.G.LOG" a écrit dans le message de 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
> 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
>
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
> 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
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 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.
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
> 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
>
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 ?
> 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
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 ;-)
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
;-)
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
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.
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é.
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é.
