{"id":55000652,"date":"2009-02-01T00:00:00","date_gmt":"2020-05-22T22:33:07","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=652"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Tipps_und_Tricks_12009","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Tipps_und_Tricks_12009\/","title":{"rendered":"Tipps und Tricks 1\/2009"},"content":{"rendered":"

\"\"<\/p>\n

Es sind die kleinen Kniffe, die uns den Alltag beim Programmieren von Access-Anwendungen erleichtern. In dieser Ausgabe von Access im Unternehmen zeigen wir Ihnen zum Beispiel, wie Sie den Datensatzwechsel in Formularen steuern, bei Problemen mit DoCmd.OpenForms reagieren oder einen kompletten Datensatz im Endlosformular markieren.<\/b><\/p>\n

Dateneingabe ohne Datensatzwechsel<\/p>\n

Wenn Sie Detaildaten wie etwa einen Kunden, einen Artikel oder ähnliches eingeben, verwenden Sie in der Regel ein entsprechendes Formular, das nur zur Eingabe dieser Daten dient.<\/p>\n

Beim Aufruf dieses Formulars geben Sie mit dem Parameter DataMode <\/b>in der folgenden Anweisung direkt an, dass nun ein neuer Datensatz eingegeben werden soll:<\/p>\n

DoCmd.OpenForm "Formularname", DataMode:=acFormAdd<\/pre>\n
Damit weiß das Formular, dass es direkt einen neuen, leeren Datensatz anzeigen und alle anderen Datensätze der Datenherkunft ausblenden soll.<\/p>\n
Wenn Sie die Eigenschaften Trennlinie<\/b>, Navigationsbereich <\/b>und Datensatzmarkierer <\/b>auf Nein <\/b>einstellen, befreien Sie das Formular überdies von unnötigem Schnickschnack, den man beim Anlegen eines einfachen Datensatzes nicht braucht.<\/p>\n
Der Benutzer kann hiermit keinen Unsinn mehr anstellen – es sei denn, er springt mit der Eingabe- oder Tabulator-Taste bis zum letzten Steuerelement in der Aktivierreihenfolge und darüber hinaus, dann gelangt er nämlich in einen neuen Datensatz.<\/p>\n
Das können Sie allerdings leicht unterbinden: Stellen Sie dazu einfach die Eigenschaft Zyklus <\/b>des Formulars auf den Wert Aktueller Datensatz <\/b>ein. Der Fokus wechselt dann vom letzten Steuerelement der Aktivierreihenfolge zum ersten Steuerelement des Formulars.<\/p>\n
DoCmd.OpenForm-Argumente funktionieren nicht<\/b><\/p>\n
Während der Entwicklung von Formularen treten manchmal nicht nachvollziehbare Probleme auf.<\/p>\n
So kann es zum Beispiel vorkommen, dass Sie ein Formular mit einer Anweisung wie der folgenden aufrufen, aber das mit dem Parameter OpenArgs<\/b> übergebene Öffnungsargument einfach nicht beim Formular ankommt:<\/p>\n
DoCmd.OpenForm "Formularname", OpenArgs:="Test"<\/pre>\n
Im Ereignis Beim Öffnen <\/b>des Formulars möchten Sie das Öffnungsargument nun so auslesen:<\/p>\n
Dim strOeffnungsargument As String\r\nstrOeffnungsargument = Me.OpenArgs<\/pre>\n
Es gibt jedoch die Fehlermeldung Laufzeitfehler 94: Unzulässige Verwendung von Null<\/b>, OpenArgs <\/b>ist also scheinbar leer.<\/p>\n
Der durch das fehlende Öffnungsargument verursachte Fehler tritt immer dann auf, wenn das Formular bereits geöffnet ist – egal, ob sichtbar oder unsichtbar. Wenn Ihnen dies passiert, ist das Formular also beispielsweise hinter einem anderen Formular versteckt oder Sie haben es unsichtbar geschaltet.<\/p>\n
Das geschieht gern, wenn Sie das Formular als modalen Dialog öffnen, um den aufrufenden Code anzuhalten, bis das Formular den Fokus verliert, um dann Elemente des Formulars auszulesen. Sie belegen dann etwa die OK<\/b>-Schaltfläche des Formulars mit folgendem Code:<\/p>\n
Me.Visible = False<\/pre>\n
Wenn Sie dann im aufrufenden Code vergessen, das Formular mit einer Anweisung wie der folgenden endgültig zu schließen, bleibt es im unsichtbaren Zustand geöffnet:<\/p>\n
DoCmd.Close acForm, "frmTest"<\/pre>\n
Das Öffnungsargument ist allerdings nicht der einzige Parameter, der an bereits geöffnete Formulare nicht übergeben wird – auch die anderen Parameter wie WhereCondition<\/b>, WindowMode<\/b>, DataMode <\/b>oder Filter <\/b>funktionieren nicht.<\/p>\n
Wenn Sie dieses Problem verhindern möchten, schließen Sie einfach immer alle geöffneten Formulare ordnungsgemäß – vor allem die unsichtbar geschalteten. Das Wichtigste ist jedoch, dass Sie das hier beschriebene Verhalten richtig einschätzen, was spätestens nach der Lektüre dieses Tipps kein Problem mehr sein sollte.<\/p>\n
Kompletten Datensatz im Datenblatt markieren<\/b><\/p>\n
Manchmal möchte man ein Datenblatt nicht zur Dateneingabe, sondern einfach nur zum Anzeigen und gegebenenfalls zum Auswählen von Daten verwenden. Damit der Benutzer keine Daten darin ändern kann, stellen Sie einfach die Eigenschaft Recordsettyp <\/b>auf Snapshot <\/b>ein – schon ist das Anfügen, ändern und Löschen der Daten nicht mehr möglich.<\/p>\n
Das ist aber auch nur die technisch notwendige Seite der Medaille. Damit der Benutzer sich nicht verschaukelt fühlt, weil er zwar die Einfügemarke in die Felder setzen, aber keine Inhalte ändern kann, unterbinden Sie auch das.<\/p>\n
Sie könnten dazu einfach die Eigenschaften Aktiviert <\/b>und Gesperrt <\/b>des Steuerelements auf Nein <\/b>und Ja <\/b>einstellen. Damit kann der Benutzer nicht mehr den Fokus auf die Steuerelemente setzen, aber leider kann er so auch den kompletten Datensatz nicht mehr einfach per Mausklick markieren.<\/p>\n
Aktiviert <\/b>und Gesperrt <\/b>sind also die falschen Eigenschaften. Wir markieren den Datensatz einfach so, wie es auch durch einen Mausklick auf den Datensatzmarkierter am linken Rand geschehen würde – und dazu verwenden Sie die folgende Anweisung:<\/p>\n
Application.RunCommand acCmdSelectRecord<\/pre>\n
Aber wann Der Datensatz soll schließlich bei einem Mausklick irgendwo in der Zeile markiert werden, was normalerweise das Anlegen entsprechender Beim Klicken<\/b>-Ereignisprozeduren für alle angezeigten Steuerelemente beziehungsweise Felder erforderlich machen würde.<\/p>\n
Das macht bei Formularen mit vielen Feldern aber keinen Spaß und deshalb lösen wir diese Anweisung einfach beim Ereignis Beim Anzeigen <\/b>aus, das bei jedem Wechseln des Datensatzes angestoßen wird.<\/p>\n
Wählen Sie dazu im Eigenschaftsfenster das Element Formular <\/b>aus, tragen Sie für die Eigenschaft Beim Anzeigen <\/b>den Wert [Ereignisprozedur] <\/b>ein und klicken Sie auf die nun erscheinende Schaltfläche neben der Eigenschaft. Die dann im VBA-Editor angelegte Routine ergänzen Sie wie folgt:<\/p>\n
Private Sub Form_Current()\r\n    Application.RunCommand acCmdSelectRecord\r\n    End Sub<\/pre>\n
Damit markiert das Formular direkt beim Anzeigen den ersten Datensatz und erledigt dies auch beim Wechseln des Datensatzes durch einen Mausklick auf einen anderen Datensatz.<\/p>\n
Wenn Sie dieses Formular nun als Unterformular in einem anderen Formular einsetzen, was bei der Verwendung von Formularen in der Datenblattansicht üblich ist, wird der erste Datensatz beim Öffnen des Formulars nicht mehr komplett markiert – dies funktioniert nur noch beim Wechseln des Datensatzes.<\/p>\n
Die Ereignisprozedur Form_Current <\/b>des Unterformulars wird zwar beim Öffnen ausgelöst, aber offensichtlich sorgt der zwischenzeitliche Wechsel zum Hauptformular dafür, dass dieses den Fokus verliert und auch der erste Datensatz nicht mehr markiert ist.<\/p>\n
Uns ist nur eine Möglichkeit bekannt, auch beim Öffnen des Formulars direkt den ersten Datensatz des Unterformulars komplett zu markieren – und zwar durch das Setzen des Timers des Hauptformulars auf ein kurzes Zeitintervall wie 1 <\/b>und Hinzufügen der folgenden Routine, die durch die Ereigniseigenschaft Bei Zeitgeber <\/b>ausgelöst wird:<\/p>\n
Private Sub Form_Timer()\r\n    Me!sfm.SetFocus\r\n    Me!sfm.Form.Vorname.SetFocus\r\n    Application.RunCommand acCmdSelectRecord\r\n    Me.TimerInterval = 0\r\n    End Sub<\/pre>\n
<\/p>\n
Durch das Einstellen der Eigenschaft TimerInterval <\/b>auf den Wert 0 <\/b>sorgen Sie dafür, dass Access die Routine nicht erneut auslöst.<\/p>\n
Eine Optimierung gibt es noch. Dabei verwenden Sie statt der SetFocus<\/b>– und RunCommand<\/b>-Methode die folgende Variante, die den Zugriff stark vereinfacht:<\/p>\n
With Me\r\n.SelTop = Me.Recordset.AbsolutePosition + 1\r\n.SelLeft = 1\r\n.SelWidth = 3\r\n.SelHeight = 1\r\nEnd With<\/pre>\n
Einen kleinen Haken hat diese Routine noch: Wenn das Unterformular keine Datensätze enthält, löst das Setzen des Fokus auf ein Feld des Datensatzes (hier Vorname) einen Fehler aus. Daher fügen Sie noch die folgende Abfrage hinzu:<\/p>\n
Private Sub Form_Timer()\r\n    Me!sfm.SetFocus\r\n    If Me!sfm.Form.Recordset.RecordCount > 0 Then\r\n        Me!sfm.Form.Vorname.SetFocus\r\n        Application.RunCommand acCmdSelectRecord\r\n    End If\r\n    Me.TimerInterval = 0\r\n    End Sub<\/pre>\n
Migration nach Access 2007<\/b><\/p>\n
Wer professionelle Datenbanken entwickelt, verwendet auch eine oder mehrere benutzerdefinierte Menüleisten darin.<\/p>\n
Wenn man eine solche Datenbank nach Access 2007 migriert, zeigt Access diese Menüleiste im Ribbon in einem eigenen Tab namens Add-Ins <\/b>an (siehe Bild 1).<\/p>\n
\"pic007.tif\"<\/p>\n
Bild 1: Menüleisten-Überbleibsel einer MDB in Access 2007<\/span><\/b><\/p>\n
Spätestens wenn Sie die Elemente der Menü- und gegebenenfalls auch der Symbolleisten als Ribbon nachgebaut haben, werden Sie die Menü- und Symbolleisten aus der Datenbank werfen.<\/p>\n
Das geht am einfachsten, indem Sie zunächst einmal prüfen, welches die Kandidaten für den Rauswurf sind, und diese mit der folgenden Routine im Direktfenster ausgeben lassen:<\/p>\n
Public Sub CommandbarsLoeschen()\r\nDim cbr As CommandBar\r\nFor Each cbr In CommandBars\r\n If Not cbr.BuiltIn Then\r\n    Debug.Print cbr.Name\r\nEnd If\r\nNext cbr\r\nEnd Sub<\/pre>\n
Danach können Sie die nicht mehr benötigten Elemente mit der folgenden Anweisung löschen:<\/p>\n
CommandBars("<Menüleiste>").Delete<\/pre>\n
Warum so zimperlich und nicht alle nicht eingebauten Menü- und Symbolleisten direkt löschen<\/p>\n
Nun: Es kann ja sein, dass die CommandBars<\/b>-Auflistung nicht nur die Elemente der aktuellen Datenbank, sondern auch solche aus Bibliotheksdatenbanken oder aus Add-In-Datenbanken enthält, und die würden Sie dann mitlöschen.<\/p>\n
Wenn Sie die Anwendung das nächste Mal starten, erscheint dann allerdings eine Fehlermeldung wie die aus Bild 2.<\/p>\n
\"pic001.tif\"<\/p>\n
Bild 2: Dieser Fehler erscheint, wenn eine noch referenzierte Symbolleiste nicht mehr vorhanden ist.<\/span><\/b><\/p>\n
Die Ursache ist klar: Irgendwo muss noch ein Verweis auf die Menüleiste sein – vermutlich in den Access-Optionen für die aktuelle Datenbank.<\/p>\n
Dort werden Sie allerdings eines Besseren belehrt: Von den von älteren Access-Versionen bekannten Elementen findet sich allenfalls noch die Option zum Festlegen eines Kontextmenüs, ansonsten können Sie hier nur das Ribbon festlegen, das beim Anwendungsstart erscheinen soll.<\/p>\n
Immerhin sind aber alle Access-Optionen per VBA erreichbar. <\/p>\n
Die hier benötigte Option heißt StartupMenuBar <\/b>und lässt sich mit der folgenden, im Direktfenster des VBA-Editors abgesetzten Anweisung löschen:\r\nCurrentDB.Properties.Delete "StartUpMenuBar"<\/pre>\n
Davon abgesehen müssen Sie natürlich auch noch die Eigenschaften Symbolleiste <\/b>und Menüleiste <\/b>von Formularen und Berichten leeren, um Fehler beim Aufrufen dieser Objekte zu verhindern.<\/p>\n
Und schließlich kann auch der VBA-Code noch auf Menü- und Symbolleisten verweisen. Hier hilft eine Suche nach Begriffen wie Commandbar<\/b>, MenuBar <\/b>oder Toolbar <\/b>und das Löschen der relevanten Codezeilen.<\/p>\n
Probleme mit DAO unter Access 2007<\/b><\/p>\n
Wer seine Datenbank im Format von Access 2003 oder älter mit Access 2007 öffnet und diese als .accdb<\/b>-Datei, also im Format von Access 2007 speichert, erlebt möglicherweise eine Überraschung bei ihrer Anwendung. Die einfachste Variante dabei ist der Einsatz der folgenden Routine in einem beliebigen Modul:<\/p>\n
Public Sub DAOBeispiel()\r\nDim db As Database\r\nDim rst As Recordset\r\nSet db = CurrentDb\r\nSet rst = db.OpenRecordset("tblKontakte", _\r\ndbOpenDynaset)\r\nDo While Not rst.EOF\r\nDebug.Print rst!Vorname, rst!Nachname\r\nrst.MoveNext\r\nLoop\r\n...\r\nEnd Sub<\/pre>\n
Wenn Sie unter Access 2003 eine Datenbank mit dieser Routine erstellen, läuft diese ohne Probleme. Wenn Sie die Datenbank allerdings unter Access 2007 öffnen und über den Eintrag Speichern|Access 2007-Datenbank <\/b>als .accdb<\/b>-Datei speichern (siehe Bild 3), funktioniert die Routine nicht mehr.<\/p>\n
\"pic003.tif\"<\/p>\n
Bild 3: Speichern einer MDB als ACCDB<\/span><\/b><\/p>\n
Die folgende Zeile liefert nämlich einen Fehler 13, Typen unverträglich<\/b>:<\/p>\n
Set rst = db.OpenRecordset("tblKontakte", _\r\ndbOpenDynaset)<\/pre>\n
Der Grund offenbart sich nach einem Blick in den Verweise-Dialog. Der sieht nämlich für eine frisch angelegte Access 2003-Datenbank so wie in Bild 4 aus.<\/p>\n
\"pic004.tif\"<\/p>\n
Bild 4: Der Verweise-Dialog einer .mdb-Datenbank vor …<\/span><\/b><\/p>\n
Konvertieren Sie die Datenbank in das Format von Access 2007, erhalten Sie das Bild aus Bild 5.<\/p>\n
\"pic005.tif\"<\/p>\n
Bild 5: … und nach der Migration in eine .accdb-Datenbank.<\/span><\/b><\/p>\n
Und dort finden Sie auch des Rätsels Lösung: Access hat den Verweis Microsoft DAO 3.6 Object Library <\/b>entfernt und dafür den Verweis auf die neue Bibliothek Microsoft Office 12.0 Access Database Engine Object <\/b>gesetzt.<\/p>\n
Das ist aber nicht der Grund für den Fehler, sondern die Reihenfolge der Verweise: Der unter Access 2003 hinter dem DAO-Verweis liegende Verweis Microsoft ActiveX Data Objects 2.1 Library <\/b>liegt nun vor dem Verweis auf die neue DAO-Bibliothek.<\/p>\n
Was spielt das nun für eine Rolle Nun: Sowohl die DAO- als auch die ADO-Objektbibliothek besitzt ein Recordset-Objekt, das allerdings grundsätzliche Unterschiede aufweist.<\/p>\n
So besitzt beispielsweise das DAO-Recordset eine Methode namens FindFirst<\/b>, unter ADO hingegen verwendet man Find <\/b>zum Suchen.<\/p>\n
Während dies immerhin einen Fehler beim Kompilieren der Anwendung auslösen würde, tut der vorliegende Fehler dies nicht: Dort passt schlicht und einfach der Typ nicht, denn db.OpenRecordset <\/b>ist definitiv eine DAO-Methode und liefert ein DAO-Recordset, das Sie aber keiner ADO-Recordset-Variablen zuweisen können.<\/p>\n
Es gibt zwei mögliche Lösungen:<\/p>\n