Bonjour !!
Se pourrait-il qu'après un Open sur un recorset il y est un temps de latence
pour que le recorset se remplisse avec le résultat d'un requête?
Je m'explique...dans mon programme à un moment je fais un MoveFirst sur mon
recordset.
sans le mode debug : celui-ci est vide, ce qui déclenche un message d'alerte.
en parcourant mon programme en mode pas-à-pas : le MoveFirst se fais sans
problèmes.
Je ne comprend pas pourquoi.
De plus dans le tree-view de mon recordset, au noeud "Fields", Count = 1.
Donc mon recordset n'est pas vide? non?
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité ! http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" a écrit dans le message de news:
| en mode pas à pas oui !!! | sinon non.. |
es-tu dans le cas évoqué par Jérome ?
--
@+
Raymond Access MVP http://OfficeSystem.Access.free.fr/
Pour débuter sur le forum: http://www.mpfa.info/
Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité !
http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" <nunurs@discussions.microsoft.com> a écrit dans le message de news:
3E82671A-97C9-42C8-B8E0-F8A30C4AE687@microsoft.com...
| en mode pas à pas oui !!!
| sinon non..
|
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité ! http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" a écrit dans le message de news:
| en mode pas à pas oui !!! | sinon non.. |
nunurs
Sachant que ce code se trouve dans une fonction, et que j'y recrée une connection sur ma base, le problème pourrait venir de là...je teste ^^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
J'ai testé alors sans le movefirst....c'est toujours pareil...en mode pas à pas ça marche impécable...sinon ça considère toujours mon recordset comme étant vide...
Bonjour.
quand tu ouvres un recordset, la procédure attend que la source soit disponible avant de continuer, donc pas de souci de ce côté là. lorsque tu fais un openrecordset il faut le faire suivre immédiatement par un test du BOF/EOF pour tester la présence d'enregistrements. Set Rs = CurrentDb.OpenRecordset("blabla") If Rs.EOF Then MsgBox "pas d'enregistrements" Exit Sub End If
après le OpenRecordset, le pointeur est positionné sur le premier enregistrement, qui est donc disponible au traitement sans opérer de positionnement First. faire un movefirst ou movelast si EOF est à True va demander un certain temps de timeout.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité ! http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" a écrit dans le message de news:
| C'est le seul endroit où le MoveFirst a du mal. | Ce code se trouve dans une fonction. | Et je travaille en local.
Sachant que ce code se trouve dans une fonction, et que j'y recrée une
connection sur ma base, le problème pourrait venir de là...je teste ^^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
-----------------------------
Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre
une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le
quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5
secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre
connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou
soit tu réutilises le même objet ADO.
Cordialement
J'ai testé alors sans le movefirst....c'est toujours pareil...en mode pas à
pas ça marche impécable...sinon ça considère toujours mon recordset comme
étant vide...
Bonjour.
quand tu ouvres un recordset, la procédure attend que la source soit
disponible avant de continuer, donc pas de souci de ce côté là.
lorsque tu fais un openrecordset il faut le faire suivre immédiatement par
un test du BOF/EOF pour tester la présence d'enregistrements.
Set Rs = CurrentDb.OpenRecordset("blabla")
If Rs.EOF Then
MsgBox "pas d'enregistrements"
Exit Sub
End If
après le OpenRecordset, le pointeur est positionné sur le premier
enregistrement, qui est donc disponible au traitement sans opérer de
positionnement First.
faire un movefirst ou movelast si EOF est à True va demander un certain
temps de timeout.
--
@+
Raymond Access MVP http://OfficeSystem.Access.free.fr/
Pour débuter sur le forum: http://www.mpfa.info/
Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité !
http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" <nunurs@discussions.microsoft.com> a écrit dans le message de news:
22892669-1F12-4A8A-B518-806BAF10D8D4@microsoft.com...
| C'est le seul endroit où le MoveFirst a du mal.
| Ce code se trouve dans une fonction.
| Et je travaille en local.
Sachant que ce code se trouve dans une fonction, et que j'y recrée une connection sur ma base, le problème pourrait venir de là...je teste ^^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
J'ai testé alors sans le movefirst....c'est toujours pareil...en mode pas à pas ça marche impécable...sinon ça considère toujours mon recordset comme étant vide...
Bonjour.
quand tu ouvres un recordset, la procédure attend que la source soit disponible avant de continuer, donc pas de souci de ce côté là. lorsque tu fais un openrecordset il faut le faire suivre immédiatement par un test du BOF/EOF pour tester la présence d'enregistrements. Set Rs = CurrentDb.OpenRecordset("blabla") If Rs.EOF Then MsgBox "pas d'enregistrements" Exit Sub End If
après le OpenRecordset, le pointeur est positionné sur le premier enregistrement, qui est donc disponible au traitement sans opérer de positionnement First. faire un movefirst ou movelast si EOF est à True va demander un certain temps de timeout.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Non Stop Mix '07 - Paris. La nouvelle scène web fête la créativité ! http://www.comscamp.com/Tracker/Redirect.ashx?linkid°64304e-439a-45c7-9d2f-c3326db58273
"nunurs" a écrit dans le message de news:
| C'est le seul endroit où le MoveFirst a du mal. | Ce code se trouve dans une fonction. | Et je travaille en local.
nunurs
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même
en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout
le formulaire concerné et cela marche impeccable.
Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
-----------------------------
Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre
une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le
quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5
secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre
connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou
soit tu réutilises le même objet ADO.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
jerome crevecoeur
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleur s. Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problè mes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.h tm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvr e une session Jet par connexion. Ainsi, on arrive rapidement à épuis er le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autr e connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) o u soit tu réutilises le même objet ADO.
Cordialement
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleur s.
Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problè mes même
en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout
le formulaire concerné et cela marche impeccable.
Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
-----------------------------
Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.h tm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvr e
une session Jet par connexion. Ainsi, on arrive rapidement à épuis er le
quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5
secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autr e
connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) o u
soit tu réutilises le même objet ADO.
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleur s. Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problè mes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.h tm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvr e une session Jet par connexion. Ainsi, on arrive rapidement à épuis er le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autr e connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) o u soit tu réutilises le même objet ADO.
Cordialement
nunurs
La solution d'attente ne lui convenait pas apparement de toute façon...
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleurs. Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
La solution d'attente ne lui convenait pas apparement de toute façon...
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleurs.
Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même
en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout
le formulaire concerné et cela marche impeccable.
Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
-----------------------------
Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre
une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le
quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5
secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre
connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou
soit tu réutilises le même objet ADO.
La solution d'attente ne lui convenait pas apparement de toute façon...
Je pense qu'un paramétrage de 6 secondes pouvait convenir.
De rien, très pénalisant cette façon de fonctionner d'ADO d'ailleurs. Bon courage pour la suite.
J'ai testé la solution de l'attente de 5s...j'ai quand eu des problèmes même en augmentant l'attente à 10s. J'ai donc gardé la même connection pour tout le formulaire concerné et cela marche impeccable. Merci pour votre aide ^__^
Bonjour,
J'ai déjà eu ce genre de problème en ADO:
----------------------------- Trouvé sur le site: http://mypage.bluewin.ch/w.stucki/MigrationADO.htm
Emploi des ressources
* DAO ouvre uniquement une seule session Jet. Par contre ADO ouvre une session Jet par connexion. Ainsi, on arrive rapidement à épuiser le quota des sessions que Jet peut gérer.
* Des sessions Jet multiples présentent un délai d'attente de 5 secondes pour s'actualiser les unes les autres.
---------------------------------
Si ton recordset est renseigné dans une autre fonction avec une autre connexion ADO, ta base sera actualisée au bout de 5 secondes.
Alors soit tu fais une pause de 5 secondes (Génial me direz-vous!) ou soit tu réutilises le même objet ADO.
Cordialement
Gloops
ze Titi a écrit, le 23/05/2007 11:57 :
Un petit DoEvents juste après l'ouverture du recordset alors...
Salut,
Le DoEvents n'a pas vocation à changer le type de jeu d'enregistrements ouvert sur la requêtre principale du formulaire.
ze Titi a écrit, le 23/05/2007 11:57 :
Un petit DoEvents juste après l'ouverture du recordset alors...
Salut,
Le DoEvents n'a pas vocation à changer le type de jeu d'enregistrements
ouvert sur la requêtre principale du formulaire.
