Warum Du trennen solltest
Access kann Businesslogik.
WordPress kann Benutzeroberfläche.
Beides zusammen ergibt ein System, das sowohl intern effizient als auch extern hübsch funktioniert.
Aber: Nur wenn Du sauber trennst.
Denn sonst entsteht Wildwuchs.
Daten werden in zwei Systemen gepflegt.
Logik wird redundant.
Und Fehler schleichen sich ein.
Die saubere Trennung
| Schicht | System | Aufgabe |
|---|---|---|
| Benutzeroberfläche | WordPress | Darstellung, Formulare, Login |
| Logik | Access VBA | Regeln, Prüfungen, Statuswechsel |
| Datenmodell | Azure SQL / ODBC | Tabellen, Views, Normalisierung |
WordPress darf keine Businesslogik enthalten.
Access kennt keine HTML-CSS-Buttons.
Datenmodelle bleiben neutral – zugänglich für beide.
Beispiel: Formular zur Liefermeldung
Im WordPress-Frontend
Der Lieferant füllt ein Formular aus.
Er sieht nur: „Liefermenge“, „Wunschtermin“, „Kommentar“.
Die Eingaben landen per REST-API im Backend.
$daten = [
'lieferung_id' => 1234,
'menge' => $_POST['menge'],
'termin' => $_POST['termin']
];
$payload = json_encode($daten);
$response = wp_remote_post('https://api.meinfirma.de/lieferung', [
'headers' => ['Content-Type' => 'application/json'],
'body' => $payload
]);
In Access
Access greift auf die gleiche Tabelle zu – z. B. tbl_Lieferungen.
Dort wird in einem Formular geprüft:
If Me.Menge > 1000 Then
MsgBox "Großmenge - Rücksprache notwendig!"
Me.Status = "intern prüfen"
Else
Me.Status = "freigegeben"
End If
Die Entscheidung, ob etwas freigegeben wird, trifft nicht das WordPress-Formular, sondern Access.
Die UI ist also dumm – und das ist gut so.
Vorteile dieser Trennung
- Kein Datenverlust durch Überschreiben
- Keine doppelten Prüfregeln
- Saubere Fehlerquellenanalyse
- Erweiterbarkeit durch klare Zuständigkeiten
Tabellen- und Viewstruktur in der Datenbank
Das Datenmodell muss für beide Systeme verständlich sein.
Verzichte auf Access-spezifische Felder wie Lookup.
Stattdessen:
- Tabellen für Rohdaten
- Views für Frontend
- Stored Procedures für Sonderlogik
Beispiel-View für WordPress:
CREATE VIEW vw_Lieferungen_aktiv AS
SELECT ID, Kunde, Menge, Lieferdatum
FROM tbl_Lieferungen
WHERE Status IN ('neu', 'offen')
Kommunikation über API
Access sendet und empfängt JSON über MSXML2.XMLHTTP.
Beispiel: Rückmeldung an WordPress, dass eine Lieferung geprüft wurde.
Public Sub SendeStatusUpdate(LieferungID As Long, StatusNeu As String)
Dim http As Object, body As String
Set http = CreateObject("MSXML2.XMLHTTP")
body = "{""id"":" & LieferungID & ",""status"":""" & StatusNeu & """}"
http.Open "POST", "https://meinportal.de/wp-json/lieferungen/update", False
http.setRequestHeader "Content-Type", "application/json"
http.Send body
End Sub
Trennung auch im Kopf
Dein Team braucht ein klares Verständnis:
- UX und Design = WordPress
- Businesslogik = Access
- Daten = Server
Nicht alles in einem Tool lösen wollen.
Kein WordPress-Plugin mit 80 Optionen.
Kein VBA, das HTML zusammenbastelt.
Mein Fazit als Datenschäfer
WordPress zeigt, was sein soll.
Access entscheidet, was sein darf.
Und wenn beides sauber getrennt ist, hast Du ein System, das verständlich, wartbar und sicher ist.
Das Schaf macht den ersten Eindruck.
Der Schäfer die Regeln.