Warum Access-Logik im Backend Sinn ergibt
Access ist bei mir mehr als eine Datenbank.
Da steckt geprüfte Fachlogik drin: Preismodelle, Zeitfenster, Validierungen, Mengengrenzen.
Und bevor ich das alles in PHP nachbaue (und später doppelt pflegen muss), nutze ich Access direkt – als Service.
WordPress holt sich die Antworten, Access liefert sie.
Architektur: WordPress fragt – Access rechnet
| Komponente | Aufgabe |
|---|---|
| WordPress | UI, Formulare, Benutzeroberfläche |
| Access | Businesslogik, Regeln, Prüfungen |
| Middleware | REST-API oder Kommando-Proxy |
WordPress kennt nur die Anfrage.
Access entscheidet, ob etwas erlaubt, gültig oder vollständig ist.
Beispiel: Liefertermin-Prüfung in Access
WordPress-Formular fragt:
„Ist der 19.07.2025 ein erlaubter Liefertag für Kunde 1048 bei Produkt 991?“
Access kennt die Regeln:
- kein Wochenende
- keine Feiertage
- max. 3 Lieferungen am selben Tag pro Kunde
- Lieferstopps pro Artikel
Ich kapsle das in eine Funktion:
Public Function IstLieferterminZulässig(KundenID As Long, ArtikelID As Long, Lieferdatum As Date) As Boolean
If Weekday(Lieferdatum, vbMonday) > 5 Then Exit Function
If Not IstKeinFeiertag(Lieferdatum) Then Exit Function
If AnzahlLieferungen(KundenID, Lieferdatum) >= 3 Then Exit Function
If ArtikelGesperrtAm(ArtikelID, Lieferdatum) Then Exit Function
IstLieferterminZulässig = True
End Function
Diese Funktion ist das Herzstück.
Die nutze ich jetzt – von außen.
Zugriff auf Access von außen: REST-Wrapper
Access selbst kann kein HTTP.
Aber Du kannst es über eine Middleware erreichbar machen.
Beispiel: Node.js-Skript, das Access via Shell aufruft
const express = require('express');
const app = express();
const { exec } = require('child_process');
app.get('/check-liefertermin', (req, res) => {
const { kunde, artikel, datum } = req.query;
const cmd = `AccessScript.exe ${kunde} ${artikel} ${datum}`;
exec(cmd, (err, stdout) => {
if (err) return res.status(500).send('Fehler');
res.json({ erlaubt: stdout.trim() === 'True' });
});
});
Du kannst auch Python, n8n oder PowerShell als Brücke nehmen.
Access-Wrapper mit Rückgabewert
Dein Access-Modul:
Public Sub CheckLieferterminShell()
Dim kunde As Long, artikel As Long, datum As Date
Dim args() As String
args = Split(Command, " ")
If UBound(args) = 2 Then
kunde = CLng(args(0))
artikel = CLng(args(1))
datum = CDate(args(2))
If IstLieferterminZulässig(kunde, artikel, datum) Then
Debug.Print "True"
Else
Debug.Print "False"
End If
Else
Debug.Print "False"
End If
End Sub
Aufrufbar z. B. über wscript.exe oder kompiliert als .exe (Access Runtime).
WordPress-Integration
Im WordPress-Formular-Frontend (z. B. mit ACF, JS oder Shortcode):
fetch('https://meinserver/api/check-liefertermin?kunde=1048&artikel=991&datum=2025-07-19')
.then(r => r.json())
.then(d => {
if (!d.erlaubt) alert("Kein gültiger Liefertermin!");
});
Oder serverseitig in PHP:
$response = wp_remote_get('https://meinserver/api/check-liefertermin?kunde=1048&artikel=991&datum=2025-07-19');
$data = json_decode(wp_remote_retrieve_body($response), true);
if (!$data['erlaubt']) {
$errors[] = "Kein gültiger Termin.";
}
Alternative: Access als COM-Objekt aus .NET
Du kannst auch Access als Backend-Logik in ein VB.NET oder C# Projekt einbinden – für langfristig stabile APIs.
Beispiel:
var access = new Microsoft.Office.Interop.Access.Application();
access.OpenCurrentDatabase(@"C:\Daten\Logik.accdb");
var result = access.Run("IstLieferterminZulässig", 1048, 991, "2025-07-19");
Dann baust Du um diesen Aufruf eine ASP.NET API oder nimmst es als DLL in Deinen Gateway auf.
Was Du damit erreichst
- Die Logik bleibt an einem Ort gepflegt
- Kein doppelter Code in Access und WordPress
- Alle Regeln nachvollziehbar, versionierbar, dokumentierbar
- Auch Drittanwendungen (z. B. SAP, Power BI, M365) können darauf zugreifen
Mein Fazit
Access ist nicht retro – es ist robust.
Und wenn Du es als Logikdienst einsetzt, wird’s sogar modern.
Die eigentliche Intelligenz steckt nicht in WordPress – sondern beim Schäfer im Stall.
WordPress fragt nur: „Darf ich?“
Und Access sagt „Jo“ – oder „Nee“.