Quand je fais rst.edit, rst =E9tant un recordset ouvert avec Dim rst As
DAO.Recordset
Set rst =3D db.OpenRecordset("Tbl_Students", DB_OPEN_DYNASET), j'obtient
ce message :
run time error 3188:
Could not update; currently locked by another session on this machine
J'ai fait le tour du code en fermant syst=E9matiquement tous les
recordsetsqu'ils soient ou non ouvert sur la m=EAme table que rst, mais
rien n'y fait.
Le probl=E8me peut-il venir d'ailleur ?
Par exemple, un formulaire ouvert et li=E9 =E0 la m=EAme table, peut-il
provoquer cela ?
Evidemment, c'est pas moi qui ai fait cette base, d'o=F9 l'embrouille.
Et il y a deux expressions qui me mettent la puce =E0 l'oreille :
Set db =3D DBEngine.Workspaces(0).Databases(0)
et
Forms![frm_1_interessent]![UFrm_1_Interessent].[Form]![Tbl_InteresseStudSta=
tus].Value
=3D KomboStatus.Value
quelle est la diff=E9rence entre DBEngine..... et DAO.database ? cette
histoire de workspace, ca permet d'ouvrir plusieurs recordset sur la
m=EAme table sans souci ? Ou c'est juste en lecture ? Parce que la base
tournait impec avec cette syntaxe, et sans un seul rst.close.
"].[Form]![Tbl_InteresseStudStatus].Value ", ca ne veut pas justement
dire que le formulaire est li=E9 =E0 la base ? Je n'avais jamais vu cette
syntaxe.
Merci beaucoup =E0 ceux qui ont des r=E9ponses, et bon week-end =E0 tous !
Perso, c'est comme ca que je procède. Mais puisque tu en parles, c'est quoi l'intérêt du = Nothin au juste ?
Merci,
Benoit
3stone
Salut,
"oualaléreur" ...c'est quoi l'intérêt du = Nothin au juste?
Le .Close ferme l'objet ouvert par Set toto = .... mais la variable garde sont allocation. En utilisant le toto = Nothing tu "désalloue" (libère) la variable.
Pour ce qui est du "DBEngine.Workspaces(0).Databases(0)" il est conseillé d'utiliser CurrentDB() à la place : http://support.microsoft.com/kb/464028/fr
Tu ne rencontreras pas de sitôt un cas ou tu devras passer par le "Workspaces() qui ne sera plus (0) par la même occasion!
"oualaléreur"
...c'est quoi l'intérêt du = Nothin au juste?
Le .Close ferme l'objet ouvert par Set toto = ....
mais la variable garde sont allocation.
En utilisant le toto = Nothing tu "désalloue" (libère) la variable.
Pour ce qui est du "DBEngine.Workspaces(0).Databases(0)"
il est conseillé d'utiliser CurrentDB() à la place :
http://support.microsoft.com/kb/464028/fr
Tu ne rencontreras pas de sitôt un cas ou tu devras passer
par le "Workspaces() qui ne sera plus (0) par la même occasion!
"oualaléreur" ...c'est quoi l'intérêt du = Nothin au juste?
Le .Close ferme l'objet ouvert par Set toto = .... mais la variable garde sont allocation. En utilisant le toto = Nothing tu "désalloue" (libère) la variable.
Pour ce qui est du "DBEngine.Workspaces(0).Databases(0)" il est conseillé d'utiliser CurrentDB() à la place : http://support.microsoft.com/kb/464028/fr
Tu ne rencontreras pas de sitôt un cas ou tu devras passer par le "Workspaces() qui ne sera plus (0) par la même occasion!
J'utilise la bonne syntaxe, mais la base que je complète est pleine de Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais fermés, et souvant même ouverts deux ou trois fois dans la même procédure. Vu que ce n'est que des pointeurs, je laisse courir. Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets, penses-tu que si on ne désalloue jamais la mémoire utilisée on ai une performance décroissante ?
merci, et à +
benoit
Bonjour Pierre,
Merci pour ces précisions.
J'utilise la bonne syntaxe, mais la base que je complète est pleine de
Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais
fermés, et souvant même ouverts deux ou trois fois dans la même
procédure. Vu que ce n'est que des pointeurs, je laisse courir.
Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours
d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets,
penses-tu que si on ne désalloue jamais la mémoire utilisée on ai
une performance décroissante ?
J'utilise la bonne syntaxe, mais la base que je complète est pleine de Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais fermés, et souvant même ouverts deux ou trois fois dans la même procédure. Vu que ce n'est que des pointeurs, je laisse courir. Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets, penses-tu que si on ne désalloue jamais la mémoire utilisée on ai une performance décroissante ?
merci, et à +
benoit
3stone
Salut,
"oualaléreur" J'utilise la bonne syntaxe, mais la base que je complète est pleine de Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais fermés, et souvant même ouverts deux ou trois fois dans la même procédure. Vu que ce n'est que des pointeurs, je laisse courir. Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets, penses-tu que si on ne désalloue jamais la mémoire utilisée on ai une performance décroissante ?
Tout ce qui est "SETer" devrait être libéré par un Nothing ! Malgré que ce n'est pas obligatoire, il est fortement recommendé de le faire.
Quant aux 'recordset' ouverts, méfie toi... chaque requête et ou sous requete ouvre une table vituelle (ou recordset), sans parler de ceux que Access ouvre pour son fonctionnement propre... Pour une requête complexe ouverte, Access peut en ouvrir plusieurs de façon interne pour l'exécution. C'est pour cela que l'on peut obtenir l'erreur "trop de tables ouvertes" alors que "visiblement" on n'a pas atteint le max.
Maintenant, il est vrai que pour quelques centaines ou milliers d'enregistrements, on ne s'appercevra sûrement de rien... mais c'est plutôt une question de méthode et de mise en oeuvre. Les bonnes méthodes une fois devenues habitudes, on se pose moins de question après ;-) De plus, cela rend la base plus solide, moins sensible. Une base scindée, même si uniquement en local, et fermer tout ce qui ne doit pas être ouvert... supprime bien des soucis!
"oualaléreur"
J'utilise la bonne syntaxe, mais la base que je complète est pleine de
Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais
fermés, et souvant même ouverts deux ou trois fois dans la même
procédure. Vu que ce n'est que des pointeurs, je laisse courir.
Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours
d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets,
penses-tu que si on ne désalloue jamais la mémoire utilisée on ai
une performance décroissante ?
Tout ce qui est "SETer" devrait être libéré par un Nothing !
Malgré que ce n'est pas obligatoire, il est fortement recommendé de le faire.
Quant aux 'recordset' ouverts, méfie toi... chaque requête et ou sous
requete ouvre une table vituelle (ou recordset), sans parler de ceux
que Access ouvre pour son fonctionnement propre...
Pour une requête complexe ouverte, Access peut en ouvrir plusieurs
de façon interne pour l'exécution.
C'est pour cela que l'on peut obtenir l'erreur "trop de tables ouvertes"
alors que "visiblement" on n'a pas atteint le max.
Maintenant, il est vrai que pour quelques centaines ou milliers d'enregistrements,
on ne s'appercevra sûrement de rien... mais c'est plutôt une question
de méthode et de mise en oeuvre. Les bonnes méthodes une fois
devenues habitudes, on se pose moins de question après ;-)
De plus, cela rend la base plus solide, moins sensible.
Une base scindée, même si uniquement en local, et fermer tout ce qui ne
doit pas être ouvert... supprime bien des soucis!
"oualaléreur" J'utilise la bonne syntaxe, mais la base que je complète est pleine de Set db = DBEngine.Workspaces(0).Databases(0) qui ne sont jamais fermés, et souvant même ouverts deux ou trois fois dans la même procédure. Vu que ce n'est que des pointeurs, je laisse courir. Par contre, pour ce qui est des Set toto = Nothing, mettons qu'au cours d'une utilisation "banale" de la base on ouvre dix ou vingt recordsets, penses-tu que si on ne désalloue jamais la mémoire utilisée on ai une performance décroissante ?
Tout ce qui est "SETer" devrait être libéré par un Nothing ! Malgré que ce n'est pas obligatoire, il est fortement recommendé de le faire.
Quant aux 'recordset' ouverts, méfie toi... chaque requête et ou sous requete ouvre une table vituelle (ou recordset), sans parler de ceux que Access ouvre pour son fonctionnement propre... Pour une requête complexe ouverte, Access peut en ouvrir plusieurs de façon interne pour l'exécution. C'est pour cela que l'on peut obtenir l'erreur "trop de tables ouvertes" alors que "visiblement" on n'a pas atteint le max.
Maintenant, il est vrai que pour quelques centaines ou milliers d'enregistrements, on ne s'appercevra sûrement de rien... mais c'est plutôt une question de méthode et de mise en oeuvre. Les bonnes méthodes une fois devenues habitudes, on se pose moins de question après ;-) De plus, cela rend la base plus solide, moins sensible. Une base scindée, même si uniquement en local, et fermer tout ce qui ne doit pas être ouvert... supprime bien des soucis!
