Zentrale Prüfprozedur erstellen

Da die Prüfung derzeit schon von zwei Feldern aus aufgerufen werden wird, erstellen Sie besser gleich eine zentrale Prozedur. Diese steht im gleichen Formular-Modul und sieht so aus:

Private Sub SucheDuplikate(strKontaktperson As String, strOrt As String)
    Dim lngAnzahl As Long

    lngAnzahl = DCount("*", "Kunden", "[Kontaktperson] = '" & strKontaktperson & "' AND [Ort] = '" & strOrt & "'")

    If lngAnzahl = 0 Then
        Me.lblDuplikate.Visible = False
    Else
        With Me.lblDuplikate
            .Visible = True
            .Caption = lngAnzahl & " Duplikate"
        End With
    End If
End Sub

Wenn Sie diese Prozedur dann von einem Change-Ereignis aus aufrufen, müssen Sie aufpassen, dass Sie in der jeweils betroffenen Textbox nicht auf die (vorherige!) Value-Eigenschaft, sondern auf die (aktuelle) Text-Eigenschaft zugreifen. Dies zeigt der folgende Code:

Private Sub Kontaktperson_Change()
    SucheDuplikate Me.Kontaktperson.Text & "", Me.Ort.Value & ""
End Sub

NULL-Werte vermeiden

Die angehängte leere Zeichenkette (& "") sorgt dafür, dass an den Zeichenketten-Parameter strKontaktperson oder strOrt keine unzulässigen NULL-Werte übergeben werden. Die Verkettung aus NULL und Zeichenkette ergibt immer eine leere Zeichenkette.

Entsprechend erfolgt der Aufruf auch für das Ort-Feld, wobei hier natürlich die Text- und Value-Eigenschaft umgekehrt einzusetzen sind:

Private Sub Ort_Change()
    SucheDuplikate Me.Kontaktperson.Value & "", Me.Ort.Text & ""
End Sub

Geben Sie nun einen neuen Datensatz ein, erscheint eine Meldung, wenn Kontaktperson und Ort bei einem anderen Datensatz komplett identisch sind:

Gleiche(r) Kontaktperson und Ort führen zu einer Warnmeldung

Geschwindigkeit prüfen

Da das Change-Ereignis bei jedem Tastenanschlag ausgelöst wird, ist es extrem geschwindigkeitsempfindlich. Sobald die Texteingabe merklich gestört wird oder gar "hängen bleibt", bis Ihre Prüfung jeweils fertig ist, werden die Benutzer das ablehnen.

Sicherheitshalber sollten Sie daher in so einer Beispiel-Datenbank auch mal einige zehntausend Daten vorbereiten, damit dieser Aspekt immer berücksichtigt wird (der Beitrag "Access: Massendaten zum Testen automatisch erzeugen" zeigt Ihnen, wie Sie zu Testzwecken ohne viel Arbeit große Mengen an Daten bereitstellen). Bei den sonst zu Testzwecken gerne benutzten zehn bis zwanzig Datensätzen klappt das schließlich immer schnell genug. Aber dann beschweren sich Ihre Benutzer in einem halben Jahr über die immer zähere Verarbeitung.

Probieren Sie diesen Code aus, so werden Sie feststellen, dass es auch für über 10.000 Datensätze schnell genug ist. Eine Verzögerung ist auf aktuellen Rechnern nicht zu bemerken. Mit erhöhtem Programmieraufwand ließe es sich noch beschleunigen, aber das ist offensichtlich nicht nötig.

Nicht vergessen sollten Sie in diesem Zusammenhang übrigens auch die eventuelle Speicherung der Tabellen in einem Netzwerk. Jede Optimierung auf Access-Seite ist hoffnungslos, wenn die Daten nur langsam durch das Netz tröpfeln.

Duplikate erkennen

Duplikate zum Datensatz im gleichen Formular: Zentrale Prüfprozedur erstellen

Auf dieser Seite

NULL-Werte vermeiden

Geschwindigkeit prüfen