Warum ich die Validierung nicht ins Web auslagere

WordPress ist gut für Darstellung.
Nicht für Geschäftslogik.
Validierung im Web führt zu Duplikaten, Workarounds, Inkonsistenz.

Access dagegen:
Lokal, sicher, klar strukturiert.
Ein Ort für alle Regeln.

Ob Daten per Formular, Schnittstelle oder Upload kommen:
Die Prüfung läuft zentral in Access.

Architektur: Datenfluss mit Validierung in Access

Schritt	Technik	Bemerkung
Webformular speichern	WordPress + MySQL	Ungeprüft, rohe Eingabe
Access liest Daten	ODBC / REST / Import	Zyklisch oder manuell
Validierung in Access	VBA + Jet-SQL	Alle Prüfregeln an einer Stelle
Rückmeldung optional	REST-Call zurück ans Web	z. B. Status setzen, Mail auslösen

So habe ich immer Kontrolle.
Egal woher die Daten kommen.

Validierung per VBA: Beispiel Kundenimport

Public Function PruefeKundendaten(kID As Long) As Boolean
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM tmpWebKunde WHERE ID=" & kID)

    If rs.EOF Then
        Debug.Print "Kein Datensatz"
        Exit Function
    End If

    If Len(rs!Name) = 0 Then
        Call FehlerLog("Name fehlt", kID)
        PruefeKundendaten = False
        Exit Function
    End If

    If Not IsNull(rs!Email) And InStr(rs!Email, "@") = 0 Then
        Call FehlerLog("Ungültige E-Mail", kID)
        PruefeKundendaten = False
        Exit Function
    End If

    PruefeKundendaten = True
End Function

Einmal zentral gepflegt.
Und auch für Daten aus Excel, API oder WordPress nutzbar.

Validierung per Jet-SQL

Oft reichen einfache Abfragen:

SELECT * FROM tmpWebKunde
WHERE (Name IS NULL OR Name = '') 
   OR (Email IS NOT NULL AND InStr(Email, '@') = 0)

Ich nutze diese Abfragen auch in Formularen oder für Reports.
„Was ist fehlerhaft?“ ist nur ein Klick.

Rückmeldung ins Websystem

Nach der Prüfung kann Access dem Websystem Bescheid sagen.
Z. B. per REST-API:

Public Sub MeldeStatusZurueck(kID As Long, statusText As String)
    Dim http As Object
    Set http = CreateObject("MSXML2.XMLHTTP")

    Dim url As String
    url = "https://webseite.de/api/setStatus?id=" & kID & "&status=" & statusText

    http.Open "GET", url, False
    http.Send
End Sub

Der Kunde sieht dann z. B. „Datensatz in Prüfung“ oder „Korrektur erforderlich“.

Webdaten nicht direkt übernehmen

Ich schreibe niemals Webdaten direkt in Produktivtabellen.
Immer erst temporär.

Tabelle	Zweck
tmpWebKunde	Rohdaten aus dem Web
tblKunde	geprüfte, echte Kunden

Import → Prüfung → Freigabe.
Alles manuell oder automatisiert.

Warum das für KMU sinnvoll ist

• Du brauchst keine Prüf-Logik in mehreren Systemen
• Änderungen sind zentral und sofort wirksam
• Du kannst auch Excel- oder API-Daten nach demselben Schema prüfen
• Du hast Logs, Fehlerberichte und Transparenz

Und: Deine Access-Nutzer müssen keine PHP-Skripte anfassen.
Und Deine Webentwickler keine Access-Formulare.

Bonus: Prüfregeln als Metadaten

Ich baue mir oft eine Prüfregel-Tabelle:

Feldname	Regel	Fehlermeldung
Name	Len([Name]) > 0	Name fehlt
Email	InStr([Email], „@“) > 0	Ungültige E-Mail-Adresse

Und werte sie dynamisch aus.
So kann ich Regeln ändern – ohne Code zu ändern.

Einmal prüfen, überall korrekt.

Ich nutze Access als Prüfstelle.
Für alles, was extern reinkommt.
Datenqualität bleibt hoch.
Und ich habe keine widersprüchliche Logik in zig Systemen.