Quelqu'un a-t-il d=E9j=E0 rencontr=E9 un probl=E8me de ce type ?
Je d=E9veloppe une base frontale qui donne acc=E8s (par des tables li=E9e=
s) =E0=20
une base de donn=E9es, qui pour le moment se trouve dans le m=EAme=20
r=E9pertoire. En ce moment la machine n'est branch=E9e =E0 aucun r=E9seau=
depuis=20
plusieurs jours, donc m=EAme si quelqu'un voulait me faire une blague, il=
=20
faudrait qu'il soit "vachement" balaise.
J'ai cr=E9=E9 un formulaire, avec un sous-formulaire dedans.
Si j'ouvre le sous-formulaire en tant que formulaire principal, tout se=20
passe bien.
Si j'ouvre le formulaire du dessus, heps, impossible d'utiliser la base=20
de donn=E9es, fichier en cours d'utilisation (erreur 3045, apprends-je si=
=20
je clique sur Aide). Apr=E8s validation du message, le formulaire=20
principal s'affiche, et l'emplacement r=E9serv=E9 au sous-formulaire rest=
e=20
en blanc.
J'ai red=E9marr=E9 Windows, et =E7a n'a rien chang=E9 au probl=E8me.
Dans le sous-formulaire, j'ai au pr=E9alable imbriqu=E9 sans souci quatre=
=20
autres niveaux de sous-formulaires, dont un repr=E9sente une relation=20
plusieurs =E0 plusieurs, et rien n'a coinc=E9. En tout, =E7a devra faire =
six=20
niveaux de formulaires imbriqu=E9s. Autant dire que dans celui du bas, il=
=20
y a des onglets.
L=E0, je n'ai plus =E0 mettre en place que le niveau sup=E9rieur, objet a=
uquel=20
appartient (relation un =E0 plusieurs) l'objet du sous-formulaire=20
litigieux (bien entendu, puisque c'est m=EAme pour =E7a que je veux le=20
mettre en sous-formulaire).
Par ailleurs, de l'objet sup=E9rieur part une autre cha=EEne de liaisons =
un=20
=E0 plusieurs, sur deux niveaux, mais seul le premier est repr=E9sent=E9,=
par=20
une liste d=E9roulante, sur le formulaire principal.
J'ai utilis=E9 la commande Outils / Documentation, pour documenter le=20
sous-formulaire, et m'assurer que le nom de l'objet sup=E9rieur, ou de sa=
=20
table, n'y appara=EEt pas, pas plus qu'un des deux objets de l'autre=20
cha=EEne, des fois que dans un moment d'=E9garement ...
Bon, ben j'ai d=FB faire une erreur, mais pas celle-l=E0, ou alors c'est =
plus subtil que =E7a.
Je n'ai sp=E9cifi=E9 les liaisons que sur papier.
Une id=E9e, quelqu'un ?
Sinon demain je vais regarder si je peux faire quelque chose de =E7a :
Toutefois, la partie sympt=F4mes d=E9marre par "in a multiuser environmen=
t",=20
or =E7a, m=EAme si c'est en projet, comme je le disais en introduction ce=
=20
n'est pas le cas, donc j'aborde cette fiche avec quelque peu de=20
circonspection.
Ah oui oups, je pressens que l'oubli que je viens de faire pourrait=20
s'av=E9rer d=E9cisif : je travaille sous Access 2003 SP2 (11.6566.8107), =
avec une base au format Access 2000 d'apr=E8s ce qui est =E9crit en barre=
de=20
titre, le tout sous Windows XP 2002 SP2.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ? Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
"Gloops" Quelqu'un a-t-il déjà rencontré un problème de ce type ?
Je développe une base frontale qui donne accès (par des tables liées) à une base de données, qui pour le moment se trouve dans le même répertoire. En ce moment la machine n'est branchée à aucun réseau depuis plusieurs jours, donc même si quelqu'un voulait me faire une blague, il faudrait qu'il soit "vachement" balaise.
J'ai créé un formulaire, avec un sous-formulaire dedans.
Si j'ouvre le sous-formulaire en tant que formulaire principal, tout se passe bien.
Si j'ouvre le formulaire du dessus, heps, impossible d'utiliser la base de données, fichier en cours d'utilisation (erreur 3045, apprends-je si je clique sur Aide). Après validation du message, le formulaire principal s'affiche, et l'emplacement réservé au sous-formulaire reste en blanc.
J'ai redémarré Windows, et ça n'a rien changé au problème.
Dans le sous-formulaire, j'ai au préalable imbriqué sans souci quatre autres niveaux de sous-formulaires, dont un représente une relation plusieurs à plusieurs, et rien n'a coincé. En tout, ça devra faire six niveaux de formulaires imbriqués. Autant dire que dans celui du bas, il y a des onglets.
Là, je n'ai plus à mettre en place que le niveau supérieur, objet auquel appartient (relation un à plusieurs) l'objet du sous-formulaire litigieux (bien entendu, puisque c'est même pour ça que je veux le mettre en sous-formulaire).
Par ailleurs, de l'objet supérieur part une autre chaîne de liaisons un à plusieurs, sur deux niveaux, mais seul le premier est représenté, par une liste déroulante, sur le formulaire principal.
J'ai utilisé la commande Outils / Documentation, pour documenter le sous-formulaire, et m'assurer que le nom de l'objet supérieur, ou de sa table, n'y apparaît pas, pas plus qu'un des deux objets de l'autre chaîne, des fois que dans un moment d'égarement ...
Bon, ben j'ai dû faire une erreur, mais pas celle-là, ou alors c'est plus subtil que ça.
Je n'ai spécifié les liaisons que sur papier.
Une idée, quelqu'un ?
Sinon demain je vais regarder si je peux faire quelque chose de ça :
Toutefois, la partie symptômes démarre par "in a multiuser environment", or ça, même si c'est en projet, comme je le disais en introduction ce n'est pas le cas, donc j'aborde cette fiche avec quelque peu de circonspection.
Ah oui oups, je pressens que l'oubli que je viens de faire pourrait s'avérer décisif : je travaille sous Access 2003 SP2 (11.6566.8107), avec une base au format Access 2000 d'après ce qui est écrit en barre de titre, le tout sous Windows XP 2002 SP2.
Salut,
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ?
Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
"Gloops"
Quelqu'un a-t-il déjà rencontré un problème de ce type ?
Je développe une base frontale qui donne accès (par des tables liées) à
une base de données, qui pour le moment se trouve dans le même
répertoire. En ce moment la machine n'est branchée à aucun réseau depuis
plusieurs jours, donc même si quelqu'un voulait me faire une blague, il
faudrait qu'il soit "vachement" balaise.
J'ai créé un formulaire, avec un sous-formulaire dedans.
Si j'ouvre le sous-formulaire en tant que formulaire principal, tout se
passe bien.
Si j'ouvre le formulaire du dessus, heps, impossible d'utiliser la base
de données, fichier en cours d'utilisation (erreur 3045, apprends-je si
je clique sur Aide). Après validation du message, le formulaire
principal s'affiche, et l'emplacement réservé au sous-formulaire reste
en blanc.
J'ai redémarré Windows, et ça n'a rien changé au problème.
Dans le sous-formulaire, j'ai au préalable imbriqué sans souci quatre
autres niveaux de sous-formulaires, dont un représente une relation
plusieurs à plusieurs, et rien n'a coincé. En tout, ça devra faire six
niveaux de formulaires imbriqués. Autant dire que dans celui du bas, il
y a des onglets.
Là, je n'ai plus à mettre en place que le niveau supérieur, objet auquel
appartient (relation un à plusieurs) l'objet du sous-formulaire
litigieux (bien entendu, puisque c'est même pour ça que je veux le
mettre en sous-formulaire).
Par ailleurs, de l'objet supérieur part une autre chaîne de liaisons un
à plusieurs, sur deux niveaux, mais seul le premier est représenté, par
une liste déroulante, sur le formulaire principal.
J'ai utilisé la commande Outils / Documentation, pour documenter le
sous-formulaire, et m'assurer que le nom de l'objet supérieur, ou de sa
table, n'y apparaît pas, pas plus qu'un des deux objets de l'autre
chaîne, des fois que dans un moment d'égarement ...
Bon, ben j'ai dû faire une erreur, mais pas celle-là, ou alors c'est
plus subtil que ça.
Je n'ai spécifié les liaisons que sur papier.
Une idée, quelqu'un ?
Sinon demain je vais regarder si je peux faire quelque chose de ça :
Toutefois, la partie symptômes démarre par "in a multiuser environment",
or ça, même si c'est en projet, comme je le disais en introduction ce
n'est pas le cas, donc j'aborde cette fiche avec quelque peu de
circonspection.
Ah oui oups, je pressens que l'oubli que je viens de faire pourrait
s'avérer décisif : je travaille sous Access 2003 SP2 (11.6566.8107),
avec une base au format Access 2000 d'après ce qui est écrit en barre de
titre, le tout sous Windows XP 2002 SP2.
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ? Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
"Gloops" Quelqu'un a-t-il déjà rencontré un problème de ce type ?
Je développe une base frontale qui donne accès (par des tables liées) à une base de données, qui pour le moment se trouve dans le même répertoire. En ce moment la machine n'est branchée à aucun réseau depuis plusieurs jours, donc même si quelqu'un voulait me faire une blague, il faudrait qu'il soit "vachement" balaise.
J'ai créé un formulaire, avec un sous-formulaire dedans.
Si j'ouvre le sous-formulaire en tant que formulaire principal, tout se passe bien.
Si j'ouvre le formulaire du dessus, heps, impossible d'utiliser la base de données, fichier en cours d'utilisation (erreur 3045, apprends-je si je clique sur Aide). Après validation du message, le formulaire principal s'affiche, et l'emplacement réservé au sous-formulaire reste en blanc.
J'ai redémarré Windows, et ça n'a rien changé au problème.
Dans le sous-formulaire, j'ai au préalable imbriqué sans souci quatre autres niveaux de sous-formulaires, dont un représente une relation plusieurs à plusieurs, et rien n'a coincé. En tout, ça devra faire six niveaux de formulaires imbriqués. Autant dire que dans celui du bas, il y a des onglets.
Là, je n'ai plus à mettre en place que le niveau supérieur, objet auquel appartient (relation un à plusieurs) l'objet du sous-formulaire litigieux (bien entendu, puisque c'est même pour ça que je veux le mettre en sous-formulaire).
Par ailleurs, de l'objet supérieur part une autre chaîne de liaisons un à plusieurs, sur deux niveaux, mais seul le premier est représenté, par une liste déroulante, sur le formulaire principal.
J'ai utilisé la commande Outils / Documentation, pour documenter le sous-formulaire, et m'assurer que le nom de l'objet supérieur, ou de sa table, n'y apparaît pas, pas plus qu'un des deux objets de l'autre chaîne, des fois que dans un moment d'égarement ...
Bon, ben j'ai dû faire une erreur, mais pas celle-là, ou alors c'est plus subtil que ça.
Je n'ai spécifié les liaisons que sur papier.
Une idée, quelqu'un ?
Sinon demain je vais regarder si je peux faire quelque chose de ça :
Toutefois, la partie symptômes démarre par "in a multiuser environment", or ça, même si c'est en projet, comme je le disais en introduction ce n'est pas le cas, donc j'aborde cette fiche avec quelque peu de circonspection.
Ah oui oups, je pressens que l'oubli que je viens de faire pourrait s'avérer décisif : je travaille sous Access 2003 SP2 (11.6566.8107), avec une base au format Access 2000 d'après ce qui est écrit en barre de titre, le tout sous Windows XP 2002 SP2.
Gloops
3stone a écrit, le 18/11/2007 14:58 :
Salut,
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ? Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
Oops,
Après avoir passé dix minutes à taper ma réponse pour expliquer q ue non, il n'y a pas de code qui ouvre cette table, je continue à regarder, et là, ça fait tilt.
Mon module de traduction comporte des appels à un certain nombre de tables -obsolètes au demeurant. Or, il se trouve que dans la nouvelle base, une des tables porte le même nom que l'une de celles qui sont appelées par le module de traduction. J'ai mis cet appel en commentaires, et ça passe comme une lettre à la poste. Du coup je vai s regarder ce qui se passe autour de cet appel, il semble manifestement qu'il y ait un peu de ménage à faire.
D'ailleurs, c'est curieux, c'est un appel à une table de segments qui bloquait, alors que dans le formulaire principal, il y a une liste qui fait appel au champ segment d'une autre table. Il y a donc tout un chemin de suivi qui mène au verrouillage.
Je ne sais pas combien de temps j'aurais mis à trouver ça moi-même, de répondre aux questions m'a amené à envisager le problème sous l'a ngle qu'il faut. Merci ... pour cette lecture en diagonale ;)
3stone a écrit, le 18/11/2007 14:58 :
Salut,
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ?
Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
Oops,
Après avoir passé dix minutes à taper ma réponse pour expliquer q ue non,
il n'y a pas de code qui ouvre cette table, je continue à regarder, et
là, ça fait tilt.
Mon module de traduction comporte des appels à un certain nombre de
tables -obsolètes au demeurant. Or, il se trouve que dans la nouvelle
base, une des tables porte le même nom que l'une de celles qui sont
appelées par le module de traduction. J'ai mis cet appel en
commentaires, et ça passe comme une lettre à la poste. Du coup je vai s
regarder ce qui se passe autour de cet appel, il semble manifestement
qu'il y ait un peu de ménage à faire.
D'ailleurs, c'est curieux, c'est un appel à une table de segments qui
bloquait, alors que dans le formulaire principal, il y a une liste qui
fait appel au champ segment d'une autre table. Il y a donc tout un
chemin de suivi qui mène au verrouillage.
Je ne sais pas combien de temps j'aurais mis à trouver ça moi-même, de
répondre aux questions m'a amené à envisager le problème sous l'a ngle
qu'il faut. Merci ... pour cette lecture en diagonale ;)
Lu en diagonale... mais, as-tu du code qui s'exécute à l'ouverture ou au chargement ? Car, dans certains cas, le code 'peut' être considérer comme autre utilisateur...
Oops,
Après avoir passé dix minutes à taper ma réponse pour expliquer q ue non, il n'y a pas de code qui ouvre cette table, je continue à regarder, et là, ça fait tilt.
Mon module de traduction comporte des appels à un certain nombre de tables -obsolètes au demeurant. Or, il se trouve que dans la nouvelle base, une des tables porte le même nom que l'une de celles qui sont appelées par le module de traduction. J'ai mis cet appel en commentaires, et ça passe comme une lettre à la poste. Du coup je vai s regarder ce qui se passe autour de cet appel, il semble manifestement qu'il y ait un peu de ménage à faire.
D'ailleurs, c'est curieux, c'est un appel à une table de segments qui bloquait, alors que dans le formulaire principal, il y a une liste qui fait appel au champ segment d'une autre table. Il y a donc tout un chemin de suivi qui mène au verrouillage.
Je ne sais pas combien de temps j'aurais mis à trouver ça moi-même, de répondre aux questions m'a amené à envisager le problème sous l'a ngle qu'il faut. Merci ... pour cette lecture en diagonale ;)
Gloops
Bonjour,
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois que j'avais ouvert une table, impossible d'accéder à une autre, base verrouillée, attendez que l'autre utilisateur l'ait déverrouillée.
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai supprimé les deux tables liées et je les ai recréées, et ensuite c'était impeccable.
Pas très longtemps puisqu'ensuite j'ai eu droit à des erreurs de protection générale à chaque fois que j'ouvrais mon formulaire, enf in là j'ai importé des morceaux de la base dans une nouvelle à partir de diverses sauvegardes, et tout finit par sembler rentrer dans l'ordre. D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs modul es en même temps, il faut ensuite aller les récupérer dans l'éditeur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
Je ne saurai probablement pas au juste ce qui a fait planter. Microsoft le saura une fois que la machine sera de nouveau en réseau.
Access 2003 SP2 sur Windows XP Pro 2002 SP2 Base de données au format Access 2000
Bonjour,
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois que
j'avais ouvert une table, impossible d'accéder à une autre, base
verrouillée, attendez que l'autre utilisateur l'ait déverrouillée.
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai
supprimé les deux tables liées et je les ai recréées, et ensuite c'était
impeccable.
Pas très longtemps puisqu'ensuite j'ai eu droit à des erreurs de
protection générale à chaque fois que j'ouvrais mon formulaire, enf in là
j'ai importé des morceaux de la base dans une nouvelle à partir de
diverses sauvegardes, et tout finit par sembler rentrer dans l'ordre.
D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires
(Fichier / Données externes / Importer), ça n'importe pas leurs modul es
en même temps, il faut ensuite aller les récupérer dans l'éditeur de
code par copier/coller, ce qui doit se faire module par module donc
c'est un peu plus long.
Je ne saurai probablement pas au juste ce qui a fait planter. Microsoft
le saura une fois que la machine sera de nouveau en réseau.
Access 2003 SP2 sur Windows XP Pro 2002 SP2
Base de données au format Access 2000
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois que j'avais ouvert une table, impossible d'accéder à une autre, base verrouillée, attendez que l'autre utilisateur l'ait déverrouillée.
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai supprimé les deux tables liées et je les ai recréées, et ensuite c'était impeccable.
Pas très longtemps puisqu'ensuite j'ai eu droit à des erreurs de protection générale à chaque fois que j'ouvrais mon formulaire, enf in là j'ai importé des morceaux de la base dans une nouvelle à partir de diverses sauvegardes, et tout finit par sembler rentrer dans l'ordre. D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs modul es en même temps, il faut ensuite aller les récupérer dans l'éditeur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
Je ne saurai probablement pas au juste ce qui a fait planter. Microsoft le saura une fois que la machine sera de nouveau en réseau.
Access 2003 SP2 sur Windows XP Pro 2002 SP2 Base de données au format Access 2000
Gloops
Gloops a écrit, le 19/11/2007 14:23 :
Bonjour,
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois qu e j'avais ouvert une table, impossible d'accéder à une autre, base verrouillée, attendez que l'autre utilisateur l'ait déverrouillée .
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai supprimé les deux tables liées et je les ai recréées, et ensuit e c'était impeccable.
Peut-être un élément de compréhension : dans la définition d'un e des deux tables, il y avait une liste déroulante basée sur l'autre.
Je l'ai supprimée dans la définition de la table d'origine, mais les tables liées ont semblé n'être indépendantes l'une de l'autre qu' une fois recréées.
Gloops a écrit, le 19/11/2007 14:23 :
Bonjour,
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois qu e
j'avais ouvert une table, impossible d'accéder à une autre, base
verrouillée, attendez que l'autre utilisateur l'ait déverrouillée .
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai
supprimé les deux tables liées et je les ai recréées, et ensuit e c'était
impeccable.
Peut-être un élément de compréhension : dans la définition d'un e des
deux tables, il y avait une liste déroulante basée sur l'autre.
Je l'ai supprimée dans la définition de la table d'origine, mais les
tables liées ont semblé n'être indépendantes l'une de l'autre qu' une
fois recréées.
Bon, eh bien voilà qu'hier soir, j'ai eu une récidive : une fois qu e j'avais ouvert une table, impossible d'accéder à une autre, base verrouillée, attendez que l'autre utilisateur l'ait déverrouillée .
Au bout du compte, une fois que ça m'avait trop pris le chou, j'ai supprimé les deux tables liées et je les ai recréées, et ensuit e c'était impeccable.
Peut-être un élément de compréhension : dans la définition d'un e des deux tables, il y avait une liste déroulante basée sur l'autre.
Je l'ai supprimée dans la définition de la table d'origine, mais les tables liées ont semblé n'être indépendantes l'une de l'autre qu' une fois recréées.
3stone
Salut,
"Gloops" [...] D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs modules en même temps, il faut ensuite aller les récupérer dans l'éditeur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
S'il perd ceux-ci, cela indique peut être justement qu'il y a un problème. Problème qu'un compactage ne peut pas toujours résoudre.
Il reste alors la possibilité de tenter un /décompile avec la prudence et action de backup préliminaire qui s'impose. http://www.trigeminal.com/usenet/usenet004.asp?1036
"Gloops"
[...]
D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires
(Fichier / Données externes / Importer), ça n'importe pas leurs modules
en même temps, il faut ensuite aller les récupérer dans l'éditeur de
code par copier/coller, ce qui doit se faire module par module donc
c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
S'il perd ceux-ci, cela indique peut être justement qu'il y a un problème.
Problème qu'un compactage ne peut pas toujours résoudre.
Il reste alors la possibilité de tenter un /décompile avec la prudence
et action de backup préliminaire qui s'impose.
http://www.trigeminal.com/usenet/usenet004.asp?1036
"Gloops" [...] D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs modules en même temps, il faut ensuite aller les récupérer dans l'éditeur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
S'il perd ceux-ci, cela indique peut être justement qu'il y a un problème. Problème qu'un compactage ne peut pas toujours résoudre.
Il reste alors la possibilité de tenter un /décompile avec la prudence et action de backup préliminaire qui s'impose. http://www.trigeminal.com/usenet/usenet004.asp?1036
"Gloops" [...] D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs mod ules en même temps, il faut ensuite aller les récupérer dans l'édite ur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
Bonne nouvelle :)
S'il perd ceux-ci, cela indique peut être justement qu'il y a un prob lème. Problème qu'un compactage ne peut pas toujours résoudre.
Un certain nombre de tables ont été générées par code, et les formulaires correspondants générés à partir d'une copie d'un modè le, par DoCmd.CopyObject ça n'a pas marché tout de suite, les choses se sont bien mieux passé es en introduisant quelques DoEvents, notamment autour de l'indexation de la table.
Il se pourrait qu'il y ait encore quelques finesses à introduire dans c e mécanisme.
Un de ces jours je tâcherai de prendre le temps d'ouvrir un fil spécifiquement sur cette question -on verra si il aura plus de succès que celui qui portait sur ma première tentative infructueuse.
Dans le fond, c'est vrai que j'aurais pu me simplifier le développement en créant dans l'analyse un objet liste, ce qui aurait permis de mettre tous ces objets dans la même table, mais il est douteux que cela aurait été plus lisible, côté analyse, d'autant que ça aurait imposé d'avoir tous les intitulés de la même taille, et toutes les clefs de la mêm e taille aussi.
Il reste alors la possibilité de tenter un /décompile avec la prude nce et action de backup préliminaire qui s'impose. http://www.trigeminal.com/usenet/usenet004.asp?1036
Très intéressant. Encore que j'aime bien la conclusion :)
3stone a écrit, le 19/11/2007 15:43 :
Salut,
"Gloops"
[...]
D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires
(Fichier / Données externes / Importer), ça n'importe pas leurs mod ules
en même temps, il faut ensuite aller les récupérer dans l'édite ur de
code par copier/coller, ce qui doit se faire module par module donc
c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
Bonne nouvelle :)
S'il perd ceux-ci, cela indique peut être justement qu'il y a un prob lème.
Problème qu'un compactage ne peut pas toujours résoudre.
Un certain nombre de tables ont été générées par code, et les
formulaires correspondants générés à partir d'une copie d'un modè le, par
DoCmd.CopyObject
ça n'a pas marché tout de suite, les choses se sont bien mieux passé es
en introduisant quelques DoEvents, notamment autour de l'indexation de
la table.
Il se pourrait qu'il y ait encore quelques finesses à introduire dans c e
mécanisme.
Un de ces jours je tâcherai de prendre le temps d'ouvrir un fil
spécifiquement sur cette question -on verra si il aura plus de succès
que celui qui portait sur ma première tentative infructueuse.
Dans le fond, c'est vrai que j'aurais pu me simplifier le développement
en créant dans l'analyse un objet liste, ce qui aurait permis de mettre
tous ces objets dans la même table, mais il est douteux que cela aurait
été plus lisible, côté analyse, d'autant que ça aurait imposé d'avoir
tous les intitulés de la même taille, et toutes les clefs de la mêm e
taille aussi.
Il reste alors la possibilité de tenter un /décompile avec la prude nce
et action de backup préliminaire qui s'impose.
http://www.trigeminal.com/usenet/usenet004.asp?1036
Très intéressant.
Encore que j'aime bien la conclusion :)
"Gloops" [...] D'ailleurs, je m'aperçois d'une chose, si j'importe des formulaires (Fichier / Données externes / Importer), ça n'importe pas leurs mod ules en même temps, il faut ensuite aller les récupérer dans l'édite ur de code par copier/coller, ce qui doit se faire module par module donc c'est un peu plus long.
L'importation d'un formulaire devrait se faire avec ses modules...
Bonne nouvelle :)
S'il perd ceux-ci, cela indique peut être justement qu'il y a un prob lème. Problème qu'un compactage ne peut pas toujours résoudre.
Un certain nombre de tables ont été générées par code, et les formulaires correspondants générés à partir d'une copie d'un modè le, par DoCmd.CopyObject ça n'a pas marché tout de suite, les choses se sont bien mieux passé es en introduisant quelques DoEvents, notamment autour de l'indexation de la table.
Il se pourrait qu'il y ait encore quelques finesses à introduire dans c e mécanisme.
Un de ces jours je tâcherai de prendre le temps d'ouvrir un fil spécifiquement sur cette question -on verra si il aura plus de succès que celui qui portait sur ma première tentative infructueuse.
Dans le fond, c'est vrai que j'aurais pu me simplifier le développement en créant dans l'analyse un objet liste, ce qui aurait permis de mettre tous ces objets dans la même table, mais il est douteux que cela aurait été plus lisible, côté analyse, d'autant que ça aurait imposé d'avoir tous les intitulés de la même taille, et toutes les clefs de la mêm e taille aussi.
Il reste alors la possibilité de tenter un /décompile avec la prude nce et action de backup préliminaire qui s'impose. http://www.trigeminal.com/usenet/usenet004.asp?1036
Très intéressant. Encore que j'aime bien la conclusion :)
