2009-05-22 3 views
2

Comme dans le titre, je suis confronté à un phénomène étrange. J'ai un formulaire qui contient deux sous-formulaires. Sur les deux sous-formulaires, j'ai un bouton qui déclenche la requery du sous-formulaire concerné. Si après avoir chargé le formulaire, je clique immédiatement sur ce bouton (actualiser le formulaire) J'obtiens l'erreur "3021: Aucun enregistrement courant" quand j'essaye d'enregistrer la valeur de la clé primaire de l'enregistrement courant dans l'événement OnCurrent à une variable. Étrangement dans le débogueur les valeurs pertinentes sont comme ceci:Form.CurrentRecord = 1 et Form.RecordSet.Absoluteposition = -1

Form.CurrentRecord=1 
    Form.RecordSet.Absoluteposition=-1 
    Form.RecordSet.RecordCount=14 
    Form.RecordSet.EOF=False 
    Form.RecordSet.BOF=False 

Notez également que lorsque le formulaire est chargé, en cas de charge, il fonctionne toujours correctement et là, je peux enregistrer la valeur de clé primaire qui est la clé primaire contenue dans le premier enregistrement.

Quelque part entre Form_Load et moi en cliquant sur ce bouton requery l'état du formulaire est désynchronisé. Je viens tout juste de passer d'Access 2003 à 2007 et, autant que je me souvienne, cette erreur ne s'est pas produite auparavant (bien que je n'aime pas cliquer sur ce bouton juste après le chargement).

Pour l'instant, j'ai une solution de contournement, mais j'aimerais vraiment comprendre comment cela peut arriver.

Répondre

0

Vous devez placer le pointeur d'enregistrement sur un enregistrement particulier dans le Recordset du formulaire via un MoveFirst ou autre. Et la valeur de retour semble être basée sur zéro au lieu de 1 basée.

Je ne peux pas reproduire l'erreur que vous obtenez en retournant -1. Définissez-vous le jeu d'enregistrements du formulaire à un jeu d'enregistrements ADO? Si tel est le cas, cela pourrait expliquer cela - les jeux d'enregistrements DAO ne renvoient jamais -1 pour l'une de ces valeurs, mais je crois qu'avant un .MoveLast un enregistrement ADO RecordCount renvoie -1. Peut-être que AbsolutePosition fait la même chose dans ADO.

Qu'est-ce que vous essayez d'accomplir? Je ne vois pas d'utilité à utiliser l'objet Recordset du formulaire quand il est beaucoup plus facile d'assigner une source d'enregistrements et de naviguer dans le RecordsetClone (qui est beaucoup plus lié au tampon d'édition/affichage du formulaire que le Recordset du formulaire). été affecté avec un jeu d'enregistrements ADO).

+0

« mais je crois que, avant un retour .MoveLast un ADO RecordCount -1 » - incorrect. Contrairement à un jeu d'enregistrements DAO, la propriété RecordCount dans ADO ne change pas simplement en naviguant EOF car toutes les lignes sont récupérées; Même lors de l'extraction asynchrone des lignes, dans l'événement _Progess, RecordCount affiche la valeur finale plutôt que le nombre de lignes extraites jusqu'à présent. Par conséquent, je ne peux pas voir comment AbsolutePosition pourrait ne pas fonctionner de la même manière. – onedaywhen

+0

Je ne peux pas répliquer le problème signalé avec .Recordset du formulaire ou le .RecordsetClone. Il retourne 0 pour le premier enregistrement chaque fois que je l'ai testé, donc je ne sais pas quel est le problème. Il ya * quelque chose que je me rappelle où le .RecordCount d'un jeu d'enregistrements ADO renvoie -1, mais comme je n'utilise pas assez souvent ADO pour stocker ces choses dans mon cerveau, je ne me souviens pas des circonstances exactes. –

+0

RecordCount renvoie -1 lorsque la propriété n'est pas prise en charge, par ex. soit le fournisseur ne le supporte pas (ce qui n'est pas le cas pour ACE/Jet, bien sûr), soit les paramètres du fournisseur ne le prennent pas en charge, par exemple. vous utilisez un curseur vers l'avant uniquement. Ce que je dis, c'est que naviguer dans l'EOF ne fera jamais changer le RecordCount, que ce soit -1 ou autre. IIRC DAO ne récupère pas toujours toutes les lignes: parfois, vous devez naviguer dans EOF pour obtenir la valeur RecordCount correcte, c'est-à-dire que la valeur RecordCount peut changer. Dans ADO, RecordCount ne change jamais, même lorsqu'il est -1 (ce qui signifie «non pris en charge»). – onedaywhen

1

S'il s'agit d'un objet ADO, vérifiez quel fournisseur OLE DB est utilisé, par ex. (Deviner)

Debug.Print Form.RecordSet.ActiveConnection.Provider 

Si par hasard il est la version 3.51, voir:

INFO: AbsolutePosition Property with JET Databases in ADO

... si vous utilisez le fournisseur d'ACE, peut-être que c'est un bug de régression ?!

0

J'ai exactement le même problème lorsque j'essaie de passer en "Design View". Je n'ai pas besoin de cliquer rapidement, je peux attendre une heure, puis faire ça et cogner! il y a cette erreur. Notez que je reçois seulement l'erreur si le sous-formulaire est toujours vide (c'est-à-dire n'inclut vraiment aucun enregistrement qui est le cas quand j'ouvre la première fenêtre.) Ainsi j'ai toujours pensé que c'était normal. La valeur AbsolutePosition est définie sur -1 lorsque le curseur ne pointe pas actuellement vers une position spécifique. En outre, cette valeur est basée sur zéro (comme mentionné par quelqu'un d'autre: la première rangée est AbsolutePosition 0). Cependant, cette position peut être -1 même si vous vous concentrez sur une ligne spécifique dans le sous-formulaire. Cela signifie que c'est inutile.

Ce que vous voulez utiliser si vous avez besoin de connaître la position actuelle du curseur est CurrentRecord. C'est un nombre qui commence à 1.J'imagine que si la liste est vide, CurrentRecord peut être défini sur 0 ou -1, ce qui signifie qu'aucune ligne n'est disponible.

J'ai utilisé tout cela dans une fonction utilisée pour calculer un total complexe de différentes colonnes, voici la page http://linux.m2osw.com/msaccess-sum-focus-recordset-problem