Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

renommer des objets foire avec access run-rime 2007???

19 réponses
Avatar
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).


Merci,
Alain

10 réponses

1 2
Avatar
Michel_D
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


Avatar
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




Avatar
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

Avatar
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



Avatar
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



Avatar
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).


Avatar
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).




Avatar
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).




Avatar
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.

Avatar
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.



1 2