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

Le
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michel_D
Le #6339731
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


Alain Bourgeois
Le #6339611
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
Le #6339601
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
Le #6339591
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
Le #6369971
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
Le #6369931
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"
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
Le #6369921
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"
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
Le #6369901
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"
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
Le #6369891
"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


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
Le #6369851
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"
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.



Publicité
Poster une réponse
Anonyme