Ziel: Access als Frontend, Daten aus MySQL oder PostgreSQL im Hintergrund

Access ist schnell gebaut. Aber wenn die Daten in MySQL oder PostgreSQL liegen, brauchst Du eine saubere Anbindung.
Ich zeig Dir, wie Du das stabil aufsetzt – mit ODBC, VBA und wenig Gefrickel.

Voraussetzung: ODBC-Treiber installieren

Für MySQL:

MySQL ODBC Connector (MySQL Connector/ODBC)

Für PostgreSQL:

psqlODBC – PostgreSQL ODBC Driver

Installieren. Richtig. Mit Adminrechten.

Variante 1: DSN-Less ODBC-Verknüpfung per VBA

Public Sub VerknuepfeMySQLTabelle()
    Dim db As DAO.Database
    Set db = CurrentDb

    Dim connStr As String
    connStr = "ODBC;DRIVER={MySQL ODBC 8.0 Unicode Driver};" & _
              "SERVER=192.168.1.10;" & _
              "DATABASE=meinprojekt;" & _
              "USER=accessuser;" & _
              "PASSWORD=geheim;" & _
              "OPTION=3"

    DoCmd.TransferDatabase acLink, "ODBC Database", connStr, acTable, "kunden", "mysql_kunden"
End Sub

Für PostgreSQL ähnlich, aber mit:

DRIVER={PostgreSQL Unicode};SERVER=192.168.1.20;PORT=5432;DATABASE=meinprojekt;

So kannst Du das Verknüpfen automatisieren – ohne DSN im System.

Variante 2: ADODB direkt in VBA verwenden

Ideal, wenn Du nur kurz Daten brauchst – z. B. für Lookup, Export oder Abgleich.

Public Sub HoleKundenVonMySQL()
    Dim conn As Object, rs As Object
    Set conn = CreateObject("ADODB.Connection")
    Set rs = CreateObject("ADODB.Recordset")

    conn.Open "Driver={MySQL ODBC 8.0 Unicode Driver};Server=192.168.1.10;Database=meinprojekt;Uid=accessuser;Pwd=geheim;"

    rs.Open "SELECT id, name FROM kunden", conn

    Do Until rs.EOF
        Debug.Print rs!name
        rs.MoveNext
    Loop

    rs.Close: conn.Close
End Sub

Das geht auch mit UPDATEs und INSERTs.

Variante 3: Tabelle manuell verknüpfen

1. Access → Externe Daten → ODBC-Datenbank
2. „Verknüpfen mit Datenquelle“ wählen
3. System-DSN (vorher angelegt) auswählen
4. Tabelle(n) auswählen

Benenn um: statt dbo_kunden → pgsql_kunden
So weißt Du, woher die Tabelle kommt.

Tipps zur Performance

• niemals SELECT *
• nur verknüpfen, was Du brauchst
• keine komplexen Formulare auf PostgreSQL-Tabellen
• Abfragen auf Serverseite definieren (z. B. Views)
• Primary Keys müssen gesetzt sein – sonst ist’s read-only

Was Access gut kann:

• einfache Datenerfassung, Anzeige, Suche
• mit MySQL/PostgreSQL arbeiten über ODBC
• Abfragen auf Views ausführen
• kleine Mengen schnell darstellen

Was Access nicht gut kann:

• keine Massenverarbeitung über ODBC
• keine Transaktionen über mehrere Systeme hinweg
• keine Trigger, keine Constraints
• keine native PostgreSQL- oder MySQL-Integration
• kein gutes Caching

Wenn Du ernsthaft mit MySQL/PostgreSQL arbeitest:
Access nur als Frontend. Businesslogik und Massenverarbeitung raus aus Access.

Best Practices

• Verbindungsdaten nie hart im Code – lieber verschlüsselt oder konfigurierbar
• System-DSN nur bei Terminalserver oder mehreren Usern
• Fehlermeldungen abfangen – Verbindungsprobleme sauber protokollieren
• Tabellen mit _ext oder _pgsql markieren zur Trennung
• keine dauerhaften Verbindungen offen lassen

MySQL und PostgreSQL verhalten sich an einigen Stellen anders als Access oder SQL Server – mal subtil, mal nervig. Wenn Du Access als Frontend nutzt, solltest Du diese Unterschiede unbedingt kennen.

1. Datentyp-Mapping ist nie 1:1

MySQL:

• BOOLEAN ist intern TINYINT(1) – True/False ist also 0/1.
• DATETIME kann Sekundenbruchteile speichern – Access nicht.
• TEXT-Felder können keine Standardwerte haben.
• AUTO_INCREMENT muss über den Primärschlüssel laufen.

PostgreSQL:

• BOOLEAN ist wirklich TRUE/FALSE – aber Access macht oft -1/0.
• SERIAL oder BIGSERIAL ersetzen Autowert-Felder.
• TIMESTAMP vs. TIMESTAMP WITH TIME ZONE → Access kennt nur lokales Date/Time.
• NUMERIC und DECIMAL sind präziser als Access-Felder, aber führen bei falscher Einstellung zu Rundungsproblemen.

👉 Tipp: Nutze beim Migrieren Tools wie SSMA oder ODBC mit klaren Konventionen – und prüfe jede Spalte, besonders Boolean, Memo/Text, AutoValue.

2. Kein direkter Jet/ACE-Support

SQL Server hat Native Access Support (JET/ACE Engine optimiert), MySQL/PostgreSQL nicht.

• Performance ist über ODBC deutlich schlechter.
• Schreibzugriffe sind riskanter (z. B. bei Memo-Feld-Änderungen).
• Viele Features wie @@IDENTITY oder Trigger-Rückgaben funktionieren nicht wie gewohnt.

👉 Tipp: Schreib nicht blind in verknüpfte Tabellen – lieber über Formulare mit klarer Validierung oder ADODB.

3. Primärschlüssel-Pflicht für Updatefähigkeit

Access will für verknüpfte Tabellen immer einen eindeutigen Primärschlüssel.

Ohne den kann Access:

• keine Änderungen speichern
• keine Navigation ermöglichen
• keine Daten löschen

In PostgreSQL und MySQL musst Du daher unbedingt PKs korrekt setzen – vor der Verknüpfung.

4. Groß-/Kleinschreibung in Feld- und Tabellennamen

PostgreSQL:

• Ist case-sensitive, wenn Du Namen in doppelten Anführungszeichen definierst ("Vorname").
• Access ist nicht case-sensitive.

Das kann zu „Tabelle nicht gefunden“ führen, wenn Du "Kunde" statt "kunde" schreibst.

👉 Tipp: Immer alles klein schreiben – auch bei Feldnamen.

MySQL:

• Verhält sich je nach Betriebssystem unterschiedlich!
  • Linux: case-sensitive
  • Windows: case-insensitive

Das führt zu schwer auffindbaren Fehlern bei Deployment auf Linux.

5. Null-Verhalten

• PostgreSQL behandelt NULL = NULL korrekt nach SQL-Standard (IS NULL statt = NULL)
• Access kann da mit „falschen“ Joins oder Filtern zicken
• MySQL erlaubt manchmal unsaubere Vergleiche (z. B. NULL = '' liefert FALSE, aber auch NULL <> '' → NULL)

👉 Tipp: Immer mit Nz() in Access arbeiten, wenn Felder optional sind.

6. Keine gespeicherten Prozeduren wie in SQL Server

Access kann keine Stored Procedures in MySQL/PostgreSQL direkt aufrufen wie in SQL Server (EXEC dbo.ProcXY).
Nur über ADODB:

conn.Execute "CALL mein_prozedurname('param1')"

Rückgaben sind oft tricky – du bekommst kein Recordset wie bei SQL Server.

7. Transaktionen funktionieren nur über ADODB – nicht DAO

Dim conn As Object
Set conn = CreateObject("ADODB.Connection")
conn.Open "ODBC...MySQL/PostgreSQL"

conn.BeginTrans
conn.Execute "INSERT INTO ..."
conn.CommitTrans

DAO (Recordset/Edit/Update) kennt das nicht zuverlässig für MySQL/PostgreSQL über ODBC.

8. Fremdschlüsselverhalten und Constraints

• Access ignoriert viele Constraints im Frontend
• MySQL/PostgreSQL bestehen auf sauberen Foreign Keys
• Access-Formulare müssen vorbereitet sein auf Fehler wie „foreign key violation“

👉 Tipp: Immer Fehler abfangen, sauber behandeln.

Fazit für Entwickler

Access spricht mit MySQL und PostgreSQL.
Nicht nativ, nicht schnell – aber stabil, wenn Du’s richtig machst.
Abfrage im Backend, Formular im Access – so bleibt’s wartbar.

Bereich	SQL Server	MySQL	PostgreSQL
Performance (ODBC)	sehr gut	okay	okay
Case sensitivity	Nein	optional	ja
Boolean	-1/0	0/1	TRUE/FALSE
Autowert	Identity	Auto_Inc	Serial
Stored Procs	native	über CALL	über CALL
Constraints	Access-freundlich	strikt	strikt
Trigger-kompatibel	ja	teilweise	gut