Diese zwei Objekte sorgen für ziemlich viel Verwirrung, deshalb halte ich es für eine gute Idee, zu versuchen, einige der Fragen dahinter zu klären

Zuerst mal ist da der RecordsetClone. Dieses Objekt gibt es seit Access 2.0, und es ermöglichte Ihnen, ein DAO-Recordset zu erhalten, das ein Clone des Recordsets war, das Access für das Formular selber verwendete. Da es ein Clone war, konnten Sie Operationen im Clone durchführen und erwarten, diese Änderungen auch im Formular selber zu sehen; Sie konnten sogar mit Hilfe des Clones navigieren (z.B. mit einem FindFirst-Aufruf). Wenn der Bookmark des Formulares mit dem des RecordsetClones synchronisiert wurde, konnten Sie im Formular einen Datensatzwechsel auslösen.

In Access 2.0, 95 und 97 stand jedoch das eigentliche Recordset des Formulares nicht für solche Zwecke zur Verfügung.

Nun zu Access 2000. Hier haben Formulare tatsächlich eine Recordset-Eigenschaft, die sowohl ein DAO- als auch ein ADO-Recordset akzeptiert. Anders als ein Clone ist dieses Recordset ein echter Zeiger auf das exakt gleiche Recordset, das vom Formular selber verwendet wird (deshalb braucht man keine Synchronisation von Bookmarks wie manchmal bei RecordsetClones). Es gibt einige wichtige Regeln zu beachten über die Interaktion dieser beiden Eigenschaften, den Dateityp, und andere Fragen, die ich versuchen werde, hier aufzulisten:

• Wenn Sie die Recordset-Eigenschaft des Formulares nicht setzen und das Formular ist in einer .MDB-Datei, dann werden die Recordset- und die RecordsetClone-Eigenschaft ein DAO 3.6 Recordset zurückgeben.
• Wenn Sie die Recordset-Eigenschaft des Formulares nicht setzen und das Formular ist in einer .ADP-Datei, dann werden die Recordset- und die RecordsetClone-Eigenschaft ein ADO 2.1 Recordset auf Basis des Jet 4.0 OLE DB Providers zurückgeben.
• Wenn Sie die Recordset-Eigenschaft des Formulares setzen, dann werden nachfolgende Aufrufe sowohl der Recordset- als auch der RecordsetClone-Eigenschaft genau den selben Recordsettyp zurückliefern, auf den Sie die Eigenschaft ursprünglich gesetzt haben.
• Die Recordset-Eigenschaft kann auf ein DAO 3.6 Recordset oder ein ADO 2.1 Recordset gesetzt werden, dass entweder auf dem Jet 3.5x OLE DB Provider basiert oder auf dem Jet 4.0 OLE DB Provider. Das trifft zu - unabhängig vom Projekt-Typ.
• Derzeit werden die o.a. ADO-Recordsets das Formular auf nur-lesbar setzen.
• In einer ADP-Datei werden Sie jedesmal, wenn Sie den RecordSetClone eines Formulares aufrufen, eine neue Instanz eines geklonten Recordsets erhalten. Anders in einer .MDB-Datei, wo Sie wie bisher auch weiterhin das gleiche Recordset und den gleichen Cursor verwenden müssen. Warum das eine Rolle spielt? Nun, nehmen wir mal Code wie den folgenden, den der Listen-/Kombinationsfeld-Assistent von Access 95/97 für ein Steuerelement anbieten würde, dass zum Navigieren zu neuen Recordsets in einem Formular dienen soll:

  Me.RecordSetClone.Find "[id] = " & Me.YourComboBox.Value
  Me.Bookmark = Me.RecordsetClone.Bookmark
  

  Diese Art von Code (evtl. mit Differenzen in der Syntax, weil die DAO-Methode normalerweise FindFirst sein würde) funktionierte gut in allen bisherigen Versionen von Access und funktioniert weiterhin in .MDBs von Access 2000. In ADPs jedoch wird dieser Code nicht richtig arbeiten, weil jeder Aufruf der RecordsetClone-Eigenschaft einen neuen Cursor zurückgibt und deshalb wird die erste "Find"-Operation nichts mit dem Recordsetclone zu tun haben, der vom Aufruf in der zweiten Zeile zurückgeliefert wird. Für Access 2000 wurde dieser Code wie folgt geändert, um diesen Unterschieden Rechnung zu tragen:

  Dim rs As ADODB.Recordset
  Set rs = Me.RecordSetClone
  rs.Find "[id] = " & Me.YourComboBox.Value
  Me.Bookmark = rs.Bookmark
  

Ich hoffe, diese Information ist nützlich für den einen oder anderen!

Probleme mit dieser Seite? Bitte kontaktieren Sie den webmaster@trigeminal.com
mit Ihren Kommentaren, Fragen oder Vorschlägen.