renommer des objets foire avec access run-rime 2007???
19 réponses
Alain Bourgeois
Bonjour,
j'ai une application access (un .mdb est distribué aux clients).
Un de mes clients l'exécute sous run-time 2007.
Cette application comprend une macro qui
1. importe une table X
2. supprime la table A
3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements),
apparemment, l'import X se passe bien, le delete A aussi, le rename non
par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur?
(c'est bête, je peux supprimer/importer des modules, mais renommer une
table sans relations semble poser plus de problèmes).
Et comme ceci cela ne passe : 1. supprime la table A 2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients). Un de mes clients l'exécute sous run-time 2007. Cette application comprend une macro qui 1. importe une table X 2. supprime la table A 3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements), apparemment, l'import X se passe bien, le delete A aussi, le rename non par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur? (c'est bête, je peux supprimer/importer des modules, mais renommer une table sans relations semble poser plus de problèmes).
Merci, Alain
Bonjour,
Et comme ceci cela ne passe :
1. supprime la table A
2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients).
Un de mes clients l'exécute sous run-time 2007.
Cette application comprend une macro qui
1. importe une table X
2. supprime la table A
3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements),
apparemment, l'import X se passe bien, le delete A aussi, le rename non
par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur?
(c'est bête, je peux supprimer/importer des modules, mais renommer une
table sans relations semble poser plus de problèmes).
Et comme ceci cela ne passe : 1. supprime la table A 2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients). Un de mes clients l'exécute sous run-time 2007. Cette application comprend une macro qui 1. importe une table X 2. supprime la table A 3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements), apparemment, l'import X se passe bien, le delete A aussi, le rename non par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur? (c'est bête, je peux supprimer/importer des modules, mais renommer une table sans relations semble poser plus de problèmes).
Merci, Alain
Alain Bourgeois
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
D'une manière ou d'une autre, j'aurai besoin de renommer la table importée ou la table d'origine. Je ne sais pas pourquoi le run-time le refuse (alors qu'il accepte qu'on remplace des modules, des macros, ... qui sont des choses bien plus graves au niveau sécurité).
Michel_D wrote:
Bonjour,
Et comme ceci cela ne passe : 1. supprime la table A 2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients). Un de mes clients l'exécute sous run-time 2007. Cette application comprend une macro qui 1. importe une table X 2. supprime la table A 3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements), apparemment, l'import X se passe bien, le delete A aussi, le rename non par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur? (c'est bête, je peux supprimer/importer des modules, mais renommer une table sans relations semble poser plus de problèmes).
Merci, Alain
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème
clair et reproductible.
La macro complète est plus compliquée:
importe x
ajoute à x les lignes de a qui ne sont pas dans x
supprimer a
renommer x.
D'une manière ou d'une autre, j'aurai besoin de renommer la table
importée ou la table d'origine. Je ne sais pas pourquoi le run-time le
refuse (alors qu'il accepte qu'on remplace des modules, des macros, ...
qui sont des choses bien plus graves au niveau sécurité).
Michel_D wrote:
Bonjour,
Et comme ceci cela ne passe :
1. supprime la table A
2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients).
Un de mes clients l'exécute sous run-time 2007.
Cette application comprend une macro qui
1. importe une table X
2. supprime la table A
3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements),
apparemment, l'import X se passe bien, le delete A aussi, le rename non
par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur?
(c'est bête, je peux supprimer/importer des modules, mais renommer une
table sans relations semble poser plus de problèmes).
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
D'une manière ou d'une autre, j'aurai besoin de renommer la table importée ou la table d'origine. Je ne sais pas pourquoi le run-time le refuse (alors qu'il accepte qu'on remplace des modules, des macros, ... qui sont des choses bien plus graves au niveau sécurité).
Michel_D wrote:
Bonjour,
Et comme ceci cela ne passe : 1. supprime la table A 2. importe une table A
Bonjour,
j'ai une application access (un .mdb est distribué aux clients). Un de mes clients l'exécute sous run-time 2007. Cette application comprend une macro qui 1. importe une table X 2. supprime la table A 3. renomme la table X en A (rename, object table)
Sous run-time 2007 (ca marche dans les autres environnements), apparemment, l'import X se passe bien, le delete A aussi, le rename non par contre (pas d'erreur, mais il ne le fait pas!)
Quelqu'un peut-il me dire la cause? Et comment éviter cette erreur? (c'est bête, je peux supprimer/importer des modules, mais renommer une table sans relations semble poser plus de problèmes).
Merci, Alain
Michel_D
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème
clair et reproductible.
La macro complète est plus compliquée:
importe x
ajoute à x les lignes de a qui ne sont pas dans x
supprimer a
renommer x.
Et comme cela :
importe x
supprime dans x les lignes de a qui sont déja dans x
ajoute les lignes qui reste de x dans a
supprime x
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
Alain Bourgeois
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
C'est encore une solution pour contourner le problème.
L'application tourne chez 83 personnes et je n'ai pas envie de faire une
modif dans 83 installations à cause d'un bug dans la version 2007.
Pourquoi MS ne les corrige-t'il pas?
Vu le nombre de bugs causés par access 2007 (y en a encore plein
d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir
l'échanger contre le 2003 (mais ca, MS le refuse).
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème
clair et reproductible.
La macro complète est plus compliquée:
importe x
ajoute à x les lignes de a qui ne sont pas dans x
supprimer a
renommer x.
Et comme cela :
importe x
supprime dans x les lignes de a qui sont déja dans x
ajoute les lignes qui reste de x dans a
supprime x
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
Alain Bourgeois
Et le jour où on doit ajouter une colonne à la table on est marron! Si le run-time est sensé être utilisable, il doit au moins pouvoir exécuter des opérations access! Et pas se planter sur la moitié des instructions!
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
Et le jour où on doit ajouter une colonne à la table on est marron!
Si le run-time est sensé être utilisable, il doit au moins pouvoir
exécuter des opérations access! Et pas se planter sur la moitié des
instructions!
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème
clair et reproductible.
La macro complète est plus compliquée:
importe x
ajoute à x les lignes de a qui ne sont pas dans x
supprimer a
renommer x.
Et comme cela :
importe x
supprime dans x les lignes de a qui sont déja dans x
ajoute les lignes qui reste de x dans a
supprime x
Et le jour où on doit ajouter une colonne à la table on est marron! Si le run-time est sensé être utilisable, il doit au moins pouvoir exécuter des opérations access! Et pas se planter sur la moitié des instructions!
Michel_D wrote:
Ca ne résoudra pas mon souci. J'ai isolé le souci pour avoir un problème clair et reproductible. La macro complète est plus compliquée: importe x ajoute à x les lignes de a qui ne sont pas dans x supprimer a renommer x.
Et comme cela :
importe x supprime dans x les lignes de a qui sont déja dans x ajoute les lignes qui reste de x dans a supprime x
Michel_D
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation
concernée, à part pour cause de maintenance ou de reconstruction de
base c'est une mauvaise idée de supprimer une table fonctionnelle
dans une base.
"Alain Bourgeois" <brolspam00@skynet.be> a écrit dans le message de news:4781444B.18137285@skynet.be...
C'est encore une solution pour contourner le problème.
L'application tourne chez 83 personnes et je n'ai pas envie de faire une
modif dans 83 installations à cause d'un bug dans la version 2007.
Pourquoi MS ne les corrige-t'il pas?
Vu le nombre de bugs causés par access 2007 (y en a encore plein
d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir
l'échanger contre le 2003 (mais ca, MS le refuse).
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Alain Bourgeois
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise, le fait de ne pas pouvoir renommer une table est un bug sévère et reproductible.
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Moi j'appelle ca une manière de justifier des bugs.
Ces tables de paramètres sont des coefficients fournis par des
ministères et sur lesquels nous n'avons pas la main. Nous changeons la
table et un module de calcul régulièrement.
Que vous trouviez la méthode bonne ou mauvaise, le fait de ne pas
pouvoir renommer une table est un bug sévère et reproductible.
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation
concernée, à part pour cause de maintenance ou de reconstruction de
base c'est une mauvaise idée de supprimer une table fonctionnelle
dans une base.
"Alain Bourgeois" <brolspam00@skynet.be> a écrit dans le message de news:4781444B.18137285@skynet.be...
C'est encore une solution pour contourner le problème.
L'application tourne chez 83 personnes et je n'ai pas envie de faire une
modif dans 83 installations à cause d'un bug dans la version 2007.
Pourquoi MS ne les corrige-t'il pas?
Vu le nombre de bugs causés par access 2007 (y en a encore plein
d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir
l'échanger contre le 2003 (mais ca, MS le refuse).
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise, le fait de ne pas pouvoir renommer une table est un bug sévère et reproductible.
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Alain Bourgeois
Pour info:
macro convertie en vb: DoCmd.Rename "xcon2", acTable, "xcon" -> Ne marche PAS sous run-time 2007 (table d'origine garde le nom xcon, pas d'exception ni de msg d'erreur)
Si je réécris en utilisant DAO: CurrentDb.TableDefs("xcon").Name = "xcon2" CurrentDb.TableDefs.Refresh ->Ca marche sous runtime 2007
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Pour info:
macro convertie en vb:
DoCmd.Rename "xcon2", acTable, "xcon" -> Ne marche PAS sous run-time
2007 (table d'origine garde le nom xcon, pas d'exception ni de msg
d'erreur)
Si je réécris en utilisant DAO:
CurrentDb.TableDefs("xcon").Name = "xcon2"
CurrentDb.TableDefs.Refresh
->Ca marche sous runtime 2007
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation
concernée, à part pour cause de maintenance ou de reconstruction de
base c'est une mauvaise idée de supprimer une table fonctionnelle
dans une base.
"Alain Bourgeois" <brolspam00@skynet.be> a écrit dans le message de news:4781444B.18137285@skynet.be...
C'est encore une solution pour contourner le problème.
L'application tourne chez 83 personnes et je n'ai pas envie de faire une
modif dans 83 installations à cause d'un bug dans la version 2007.
Pourquoi MS ne les corrige-t'il pas?
Vu le nombre de bugs causés par access 2007 (y en a encore plein
d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir
l'échanger contre le 2003 (mais ca, MS le refuse).
macro convertie en vb: DoCmd.Rename "xcon2", acTable, "xcon" -> Ne marche PAS sous run-time 2007 (table d'origine garde le nom xcon, pas d'exception ni de msg d'erreur)
Si je réécris en utilisant DAO: CurrentDb.TableDefs("xcon").Name = "xcon2" CurrentDb.TableDefs.Refresh ->Ca marche sous runtime 2007
Michel_D wrote:
reBonjour,
Perso, c'est ton approche qui est mauvaise concernant la manipulation concernée, à part pour cause de maintenance ou de reconstruction de base c'est une mauvaise idée de supprimer une table fonctionnelle dans une base.
"Alain Bourgeois" a écrit dans le message de news:
C'est encore une solution pour contourner le problème. L'application tourne chez 83 personnes et je n'ai pas envie de faire une modif dans 83 installations à cause d'un bug dans la version 2007. Pourquoi MS ne les corrige-t'il pas? Vu le nombre de bugs causés par access 2007 (y en a encore plein d'autres), tous mes clients ayant le 2007 seraient heureux de pouvoir l'échanger contre le 2003 (mais ca, MS le refuse).
Michel_D
"Alain Bourgeois" a écrit dans le message de news:
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve que la méthode est mauvaise car sur une base en production cette altération de la structure fonctionnelle est critique et de plus cela a un impact sur les performances de la base car vous augmentez le volume de la base inutilement.
"Alain Bourgeois" <brolspam00@skynet.be> a écrit dans le message de news:4781F37D.5DAFB498@skynet.be...
Moi j'appelle ca une manière de justifier des bugs.
Ces tables de paramètres sont des coefficients fournis par des
ministères et sur lesquels nous n'avons pas la main. Nous changeons la
table et un module de calcul régulièrement.
Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve
que la méthode est mauvaise car sur une base en production cette
altération de la structure fonctionnelle est critique et de plus cela a
un impact sur les performances de la base car vous augmentez le volume
de la base inutilement.
"Alain Bourgeois" a écrit dans le message de news:
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve que la méthode est mauvaise car sur une base en production cette altération de la structure fonctionnelle est critique et de plus cela a un impact sur les performances de la base car vous augmentez le volume de la base inutilement.
Alain Bourgeois
Si ce principe est si mauvais, pourquoi autoriser le rename dans une macro??? Laisser des fonctionnalités qui ne fonctionnent pas est un non-sens.
Michel_D wrote:
"Alain Bourgeois" a écrit dans le message de news:
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve que la méthode est mauvaise car sur une base en production cette altération de la structure fonctionnelle est critique et de plus cela a un impact sur les performances de la base car vous augmentez le volume de la base inutilement.
Si ce principe est si mauvais, pourquoi autoriser le rename dans une
macro???
Laisser des fonctionnalités qui ne fonctionnent pas est un non-sens.
Michel_D wrote:
"Alain Bourgeois" <brolspam00@skynet.be> a écrit dans le message de news:4781F37D.5DAFB498@skynet.be...
Moi j'appelle ca une manière de justifier des bugs.
Ces tables de paramètres sont des coefficients fournis par des
ministères et sur lesquels nous n'avons pas la main. Nous changeons la
table et un module de calcul régulièrement.
Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve
que la méthode est mauvaise car sur une base en production cette
altération de la structure fonctionnelle est critique et de plus cela a
un impact sur les performances de la base car vous augmentez le volume
de la base inutilement.
Si ce principe est si mauvais, pourquoi autoriser le rename dans une macro??? Laisser des fonctionnalités qui ne fonctionnent pas est un non-sens.
Michel_D wrote:
"Alain Bourgeois" a écrit dans le message de news:
Moi j'appelle ca une manière de justifier des bugs. Ces tables de paramètres sont des coefficients fournis par des ministères et sur lesquels nous n'avons pas la main. Nous changeons la table et un module de calcul régulièrement. Que vous trouviez la méthode bonne ou mauvaise
C'est le principe même du fonctionnement des bases données qui trouve que la méthode est mauvaise car sur une base en production cette altération de la structure fonctionnelle est critique et de plus cela a un impact sur les performances de la base car vous augmentez le volume de la base inutilement.