Warum ich Access nicht aufgebe – auch wenn WordPress im Frontend glänzt

Zwei Systeme, zwei Stärken

WordPress ist hübsch.
Es ist erreichbar, responsiv, pluginreich.
Und ideal fürs Frontend – für Formulare, Uploads, Portale, Kundenbereiche.

Aber Access bleibt bei mir.
Weil Access Dinge kann, die WordPress nie gelernt hat.
Und weil KMU andere Prioritäten haben als Agenturen mit Designpreis-Ambitionen.

Was Access besser kann

1. Komplexe Datenmanipulation

Mehrere verknüpfte Tabellen in einer Maske, mit direktem Zugriff und Validierung im gleichen Formular?
Mit WordPress? Vergiss es.

In Access:

If Me.Feld1 > 100 And Me.Feld2 = "X" Then
    Me.Feld3 = Me.Feld1 * 0.75
End If

Direkt. Ohne Hook, Filter, AJAX und Theme-Kompatibilität.

2. Schnellere Entwicklung

In Access:

  • Neue Tabelle
  • Formular per Doppelklick
  • VBA-Code in 10 Minuten
  • Lösung steht

In WordPress:

  • Custom Post Type registrieren
  • ACF-Felder anlegen
  • Form Plugin suchen
  • Shortcode basteln
  • Styling anpassen
  • Benutzerrolle prüfen
  • Security durchgehen
  • Cache leeren
  • Und dann… vielleicht fertig

3. Rechtevergabe auf Feldebene

Access kann Felder ein-/ausblenden oder sperren je nach Benutzerrolle.
WordPress? Kann mit Plugins vielleicht Felder zeigen oder nicht – aber in der Datenbank bleibt alles sichtbar.

4. Lokale Datenverarbeitung (DSGVO)

Manche Daten will ich nicht im Web haben.
Access läuft lokal.
Mit passender Tabellenstruktur:

CREATE TABLE tbl_Personal (
    PersonalID COUNTER PRIMARY KEY,
    Name TEXT(100),
    Geburtsdatum DATE,
    Gehalt CURRENCY
)

Kein WP-Admin hat da Zugriff.
Keine API. Kein Angriffspunkt.
Und das ist manchmal genau das, was ein Kunde braucht.

Warum WordPress trotzdem glänzt

WordPress ist stark bei:

  • Portalen mit mehreren Rollen
  • öffentlichen Formularen
  • strukturierter Darstellung für Externe
  • SEO und Marketing
  • schnellen mobilen Zugriffen

Beispiel: Ein Lieferantenportal.
Das Frontend baut WordPress.
Aber die Lieferscheine, Teilmengen, Chargen? Die pflege ich in Access – und synce nur die genehmigten Daten.

Beispiel: Kombination Access ↔ WordPress

In Access:

Public Sub ExportiereNachWP(LieferscheinID As Long)
    Dim http As Object
    Set http = CreateObject("MSXML2.XMLHTTP")
    http.Open "POST", "https://meinportal.de/wp-json/meineapi/v1/lieferschein", False
    http.setRequestHeader "Content-Type", "application/json"
    http.setRequestHeader "Authorization", "Bearer geheimtoken"

    http.Send "{""id"":" & LieferscheinID & ",""status"":""freigegeben""}"
End Sub

In WordPress:

add_action('rest_api_init', function () {
    register_rest_route('meineapi/v1', '/lieferschein', [
        'methods' => 'POST',
        'callback' => 'speichere_lieferschein',
        'permission_callback' => '__return_true'
    ]);
});

function speichere_lieferschein($req) {
    $daten = $req->get_json_params();
    $id = $daten['id'];

    // Weiterverarbeitung oder Anzeige
    return ['status' => 'ok', 'id' => $id];
}

Meine Strategie

  • Access für Pflege, Analyse, Import/Export
  • WordPress für Anzeige, Kommunikation, Mobilzugriff
  • Verbindung über REST oder Datenexport
  • Kein Entweder-Oder. Sondern bewusst kombiniert.

Mein Fazit

Access lebt.
Und es lebt gut – wenn Du weißt, wofür.
WordPress ist das Schaf. Access ist der Schäferhund im Hintergrund.
Ich brauch beide. Du vielleicht auch.

Kategorien:

Allgemein

Schlagwörter:

AccessVergleichWordPress