Ziel: Access im Backend, Web im Frontend – oder umgekehrt

Access ist schnell gemacht – aber kein Websystem.
Du willst Daten austauschen mit:

• Kundenportalen
• Shops
• Webseiten
• Onlineformularen
• oder Web-APIs

Access kann das. Solange Du weißt, was Du tust.

Variante 1: Access exportiert – Web liest

Access erzeugt regelmäßig eine Datei (CSV, JSON, Excel), die eine Webanwendung einliest.

Beispiel: CSV-Export für Webimport

Public Sub ExportiereCSV()
    DoCmd.TransferText acExportDelim, , "qryProdukte", "C:\inetpub\wwwroot\import\produkte.csv", True
End Sub

Die Webseite liest z. B. per Cronjob den Inhalt und aktualisiert die Datenbank.

Variante 2: Web sendet → Access liest

Du bekommst Daten per FTP, Mail oder Webhook.
Access holt sie ab oder wird durch einen Sync-Prozess befüllt.

Beispiel: JSON-Datei lokal verarbeiten

Public Sub LeseJSONDatei()
    Dim f As Integer, inhalt As String
    f = FreeFile
    Open "C:\inetpub\wwwroot\uploads\auftrag.json" For Input As #f
    inhalt = Input$(LOF(f), f)
    Close #f

    MsgBox inhalt
End Sub

Dann parsen, prüfen, speichern.

Variante 3: Access sendet Daten an eine Web-API

Z. B. um Webformulare mit Bestelldaten zu füttern.

Public Sub SendeAnWebAPI()
    Dim http As Object
    Set http = CreateObject("MSXML2.XMLHTTP")

    http.Open "POST", "https://shop.deinefirma.de/api/bestellung", False
    http.setRequestHeader "Content-Type", "application/json"
    http.Send "{""kunde"":""4711"",""artikel"":""A-123"",""menge"":2}"
End Sub

So kannst Du Formulare oder Warenkörbe automatisch befüllen.

Variante 4: Access als Backend für Webanwendung – nicht empfehlenswert

Kann man machen, sollte man nicht:

• keine gleichzeitige Schreibzugriffe
• keine Transaktionen
• keine native Webschnittstelle

Wenn Du’s trotzdem versuchst:

• Access-Datei in App_Data-Ordner
• über ODBC oder ACE-Provider einbinden
• Webseite liest nur (nicht schreibt)

Besser: Datenbank in SQL Server migrieren → Access als Editor, Webseite als Viewer

Variante 5: Webanwendung schreibt direkt in SQL Server – Access nutzt dasselbe Backend

Das ist die saubere Lösung.

1. Web-Frontend (z. B. PHP, Node.js, .NET, etc.) schreibt in dbo.Kunden
2. Access nutzt verknüpfte Tabelle dbo_Kunden
3. Keine Importe, kein FTP, kein JSON – echte Datenbankintegration

Du musst nur auf saubere Sperr- und Validierungslogik achten.

Variante 6: Formulareingaben aus Websystem übernehmen

Formular ausfüllen auf der Webseite → Daten landen in z. B. new_entries.csv → Access liest regelmäßig ein:

Public Sub ImportiereFormularCSV()
    DoCmd.TransferText acImportDelim, , "tblKontaktanfragen", "C:\inetpub\wwwroot\input\kontakt.csv", True
End Sub

Achte auf: Duplikatprüfung, Encoding (UTF-8) und Bereinigung.

Was Access nicht gut kann

• direkt Webserver sein
• APIs bereitstellen
• simultane Webzugriffe handeln
• moderne Authentifizierung
• HTTPS ohne Umweg

Willst Du Daten wirklich „live“ im Web bereitstellen, musst Du über Azure, SQL oder REST-Middleware gehen.

Best Practices

• Daten immer strukturieren: kein Freitextfeld-Murks
• UTF-8 verwenden bei Export
• GET/POST nur mit Authentifizierung nutzen
• Änderungen protokollieren (z. B. mit tblWebSyncLog)
• Zeitsteuerung per Windows Task Scheduler oder Access-Timer

Fazit für Entwickler

Access und Web ist kein Widerspruch.
Aber Du brauchst Disziplin.
Access als Steuereinheit, Web als Oberfläche – oder umgekehrt – das geht.
Nur eben nicht alles gleichzeitig und schon gar nicht automatisch.