En v11.6.2 les fichiers "attachés" ne sont en fait que de simples liens absolus. Ce qui suppose d'avoir la même structure de fichiers d'un ordinateur à l'autre.
Serait-il possible de proposer en option d'encapsuler les fichiers dans le dossier *.cbf
Avantage = plus de problème de lien si le dossier cbf est déplacé
Inconvénient à assumer: augmentation de la taille du fichier *.cbf
Pour ce qui est des liens, à minima accepter les liens relatifs.
Excellent outil.
Cordialement
Proposer en option l'encapsulation des fichiers attachés
Modérateurs : Support Technique, Admin
Re: Proposer en option l'encapsulation des fichiers attachés
Bonjour,
Je supporte aussi l'idée que les liens vers les documents soient "dynamiques".
Ayant eu récemment à modifier le nom du dossier principal de mon administratif, j'ai dû tout ressaisir au niveau des fichiers attachés car on ne peut pas indiquer à MSCB un dossier racine dans lequel il irait rechercher dans les sous-dossiers si lesdits documents sont présents.
Je supporte aussi l'idée que les liens vers les documents soient "dynamiques".
Ayant eu récemment à modifier le nom du dossier principal de mon administratif, j'ai dû tout ressaisir au niveau des fichiers attachés car on ne peut pas indiquer à MSCB un dossier racine dans lequel il irait rechercher dans les sous-dossiers si lesdits documents sont présents.
-
- Site Admin
- Messages : 2743
- Inscription : 19 oct. 2004, 21:03
Re: Proposer en option l'encapsulation des fichiers attachés
Vous avez la possibilité d'indiquer un chemin relatif en précisant le répertoire :

En indiquant un répertoire racine "personnel" (ou le standard Mes Documents de Windows), les chemins d'accès sont relatifs à celui ci ($perso/....)
Evidemment chaque fichier attachés doit se retrouver dans ce dossier personnel ou un de ses sous répertoires
L'encapsulation dans la base de données n'est pas décemment possible pour des raisons de taille de fichier de base de données, forcément de performance et de lenteur dans les mises à jour. Sans compter qu'une taille trop importante va ralentir les processus de synchronisation avec les clouds.

En indiquant un répertoire racine "personnel" (ou le standard Mes Documents de Windows), les chemins d'accès sont relatifs à celui ci ($perso/....)
Evidemment chaque fichier attachés doit se retrouver dans ce dossier personnel ou un de ses sous répertoires
L'encapsulation dans la base de données n'est pas décemment possible pour des raisons de taille de fichier de base de données, forcément de performance et de lenteur dans les mises à jour. Sans compter qu'une taille trop importante va ralentir les processus de synchronisation avec les clouds.
Le Support Technique
Re: Proposer en option l'encapsulation des fichiers attachés
Merci pour votre retour rapide.
J'ai dû louper un truc car je n'ai pas bien réussi à faire marcher cette fonction et je ne vais pas m'amuser à défaire pour retester
J'ai dû louper un truc car je n'ai pas bien réussi à faire marcher cette fonction et je ne vais pas m'amuser à défaire pour retester

Re: Proposer en option l'encapsulation des fichiers attachés
Merci au support technique pour la réponse.
Mais la réponse n'est pas bonne:
Rendre un chemin dépendant de $perso c'est exactement comme le rendre dépendant de la racine du disque(C:\). Donc ce n'est pas un chemin relatif.
Ce qu'il faudrait c'est pouvoir indiquer un chemin relatif PAR RAPPORT au répertoire qui contient le fichier cbf.
Exemple:
Si mon fichier titi.cbf est rangé dans C:\TOTO
Monfichier sera donc C:\TOTO\titi.cbf
Supposons que je veuille ranger mes fichiers dans un sous répertoire FICHIERS du répertoire TOTO,
il faudrait que je puisse indiquer comme chemin pour un fichier tata.pdf rangé dans ce sous répertoire:
./FICHIERS/tata.pdf
En fait il faudrait juste que le champ du répertoire puisse être éditable manuellement. Windows fait le reste.
Mais en l'état actuel des choses, si on utilise le même dossier cbf sur deux ordi différents, ceux ci doivent avoir la même structure de fichiers, ce qui n'est pas forcément le cas.
Alors qu'avec des chemins relatifs (des vrais) il suffirait d'exporter ou zipper le répertoire.
Pour l'encapsulation des fichiers, il est exact que cela rallongerait le temps de chargement, mais avec les machines actuelles.... ou le proposer en option ?
Cordialement.
Mais la réponse n'est pas bonne:
Rendre un chemin dépendant de $perso c'est exactement comme le rendre dépendant de la racine du disque(C:\). Donc ce n'est pas un chemin relatif.
Ce qu'il faudrait c'est pouvoir indiquer un chemin relatif PAR RAPPORT au répertoire qui contient le fichier cbf.
Exemple:
Si mon fichier titi.cbf est rangé dans C:\TOTO
Monfichier sera donc C:\TOTO\titi.cbf
Supposons que je veuille ranger mes fichiers dans un sous répertoire FICHIERS du répertoire TOTO,
il faudrait que je puisse indiquer comme chemin pour un fichier tata.pdf rangé dans ce sous répertoire:
./FICHIERS/tata.pdf
En fait il faudrait juste que le champ du répertoire puisse être éditable manuellement. Windows fait le reste.
Mais en l'état actuel des choses, si on utilise le même dossier cbf sur deux ordi différents, ceux ci doivent avoir la même structure de fichiers, ce qui n'est pas forcément le cas.
Alors qu'avec des chemins relatifs (des vrais) il suffirait d'exporter ou zipper le répertoire.
Pour l'encapsulation des fichiers, il est exact que cela rallongerait le temps de chargement, mais avec les machines actuelles.... ou le proposer en option ?
Cordialement.
-
- Site Admin
- Messages : 2743
- Inscription : 19 oct. 2004, 21:03
Re: Proposer en option l'encapsulation des fichiers attachés
Un chemin relatif est toujours relatif par rapport à quelque chose
Ici le problème c'est que le répertoire $perso a une valeur stockée dans le fichier. Il faudrait juste que cette information soit stockée sur le PC de sorte qu'elle puisse être différente d'un PC à un autre. Et là, cela fonctionnerait mieux...
Nous soumettons ceci aux développeurs
Ici le problème c'est que le répertoire $perso a une valeur stockée dans le fichier. Il faudrait juste que cette information soit stockée sur le PC de sorte qu'elle puisse être différente d'un PC à un autre. Et là, cela fonctionnerait mieux...
Nous soumettons ceci aux développeurs
Le Support Technique