Fichier en cours d'utilisation

Le
Gloops
Bonjour tout le monde,

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ée=
s) à
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 rest=
e
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 a=
uquel
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 :

http://support.microsoft.com/?scid=kb%3Ben-us%3B94035&x=17&y=17

Toutefois, la partie symptômes démarre par "in a multiuser environmen=
t",
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.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
3stone
Le #6378721
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...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)


"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 :

http://support.microsoft.com/?scid=kb%3Ben-us%3B94035&x&y

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
Le #6336221
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 ;)

Gloops
Le #6335561
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
Gloops
Le #6335551
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.

3stone
Le #6335411
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

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Gloops
Le #6335271
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 :)

Publicité
Poster une réponse
Anonyme