In vielen Unternehmen ist die Borland Database Engine (BDE) bis heute Teil geschäftskritischer Delphi-Anwendungen: gewachsene Fachlogik, UI-nahe Datenzugriffe mit TTable/TQuery, teils noch Paradox/dBase, teils frühe Client/Server-Installationen. Häufig lautet die Realität: Die Software läuft, die Anwender kennen die Prozesse, und im Tagesgeschäft gibt es keinen unmittelbaren Anlass, „etwas anzufassen“. Gleichzeitig verändert sich der technische Untergrund: Betriebssysteme werden gehärtet, Deployment wird standardisiert, 64‑Bit wird erwartet, und die Datenhaltung soll auf Datenbankservern mit sauberem Rechte- und Backup-Konzept stattfinden.
Genau an dieser Stelle wird „Borland BDE durch BDE-Ablosung mit nativer Anbindung ersetzen“ zu einer strategischen Modernisierungsaufgabe. BDE-Ablosung mit nativer Anbindung ist in aktuellen Delphi-Versionen der etablierte Datenzugriff für moderne Datenbanken. Er liefert konsistentes Verhalten, robuste Treiber, Unicode-Unterstützung, Monitoring/Tracing und eine Architektur, die Desktop-Clients ebenso wie Services und REST-Server bedienen kann. Der Umstieg ist aber selten nur ein 1:1-Komponententausch – insbesondere dann nicht, wenn die Bestandsanwendung über Jahre BDE-spezifisches Verhalten „eingepreist“ hat (Transaktionsannahmen, Datenformate, Filter/Sortierungen, Cached Updates, Third-Party-Reports).
Dieser Beitrag fokussiert das praktische Vorgehen: Wie ersetzen Sie die BDE durch FireDAC, ohne die Fachlogik zu gefährden und ohne einen Big-Bang-Relaunch zu erzwingen? Sie erhalten ein umsetzbares Modell, technische Zielbilder und Hinweise zu typischen Problemzonen im Unternehmensbetrieb.
Warum die BDE-Ablösung heute mehr als Technikpflege ist
Solange eine BDE-Anwendung funktioniert, wirkt eine Ablösung wie ein reines „Code-Aufräumen“. In der Praxis entsteht der Druck jedoch meist aus Betriebs- und Risikothemen.
Deployment, Security-Baselines und „No-Touch“-Clients
Die BDE ist historisch auf lokale Konfiguration ausgelegt (BDE Administrator, Alias-Definitionen, NetDir, gemeinsame Konfigurationsdateien). In modernen Umgebungen sind manuelle Schritte und maschinenweite Einstellungen schwer vereinbar mit Softwareverteilung, Härtung und Auditierbarkeit. FireDAC erlaubt deutlich kontrollierbarere Deployments, weil Verbindungsparameter und Treibereinstellungen anwendungsnah verwaltet werden können.
64‑Bit, Windows-Modernisierung und neue Plattformziele
Spätestens wenn eine Anwendung in 64‑Bit laufen muss (Speicherbedarf, Treiber-/Office-Ökosystem, neue Hardware, Terminalserver-Strategien), wird die BDE faktisch zum Blocker. FireDAC unterstützt 32/64‑Bit konsistent und ist damit ein Kernbaustein jeder Delphi Modernisierung, die technisch nicht am Datenzugriff scheitern darf. Nebenbei werden Themen wie Windows 11 ARM64 und hybride Client/Service-Architekturen überhaupt erst sauber planbar.
Datenbankstrategie: weg von dateibasiert, hin zu serverbasiert
Viele BDE-Anwendungen tragen noch Altlasten aus Paradox/dBase-Zeiten. Diese Dateidatenbanken sind im Mehrbenutzerbetrieb anfälliger, administrativ schwieriger zu sichern und passen schlecht zu heutigen Anforderungen (Rollen/Rechte, Verschlüsselung, Monitoring, Hochverfügbarkeit). FireDAC ist zwar nicht „der neue Paradox-Treiber“, aber der moderne Zugang zu SQL Server, PostgreSQL, MariaDB und Firebird. In der Praxis ist die BDE-Ablösung daher häufig das Startsignal, Datenhaltung und Betrieb zu professionalisieren.
Wartbarkeit und Diagnosefähigkeit im Betrieb
Ein unterschätzter Kostenfaktor ist die Fehlersuche: sporadische Locking-Probleme, inkonsistentes Cursorverhalten, schwer nachvollziehbare Parameterkonvertierungen oder Netzwerk-/Pfadthemen. FireDAC bietet mit Logging, Monitoring und klarerem Typverhalten bessere Ansatzpunkte für reproduzierbare Fehleranalysen. Für Unternehmen, die eine Anwendung langfristig betreiben und punktuell erweitern wollen, ist das unmittelbarer Nutzen.
BDE vs. FireDAC: Unterschiede, die in der Migration zählen
Auf dem Papier lassen sich Komponenten zuordnen. In der Realität geht es um Verhaltensänderungen, die fachliche Seiteneffekte erzeugen können. Eine kurze Orientierung:
Komponenten-Mapping (als Startpunkt)
- TDatabase (BDE) → TFDConnection (FireDAC)
- TQuery (BDE) → TFDQuery
- TTable (BDE) → TFDTable (in Modernisierungen oft besser: Query-/View-basierter Zugriff)
- TStoredProc (BDE) → TFDStoredProc
Die häufigsten Verhaltensdifferenzen
- Parameter und Datentypen: FireDAC arbeitet präziser. „Wird schon gehen“-SQL fällt schneller auf (z. B. Datumswerte als Strings, implizite Konvertierungen, unklare Nullability).
- Transaktionen: Legacy-Code enthält oft implizite Commit-Annahmen (Dataset schließen, AutoCommit-ähnliche Muster, Cached Updates). Bei FireDAC lohnt sich bewusste Transaktionssteuerung, weil sie fachliche Konsistenz verbessert.
- Cursor/Fetch: FireDAC hat andere Defaults und mehr Stellschrauben. Ineffiziente Muster (große Resultsets für UI-Listen) werden sichtbarer, können aber gezielt optimiert werden.
- Unicode: In modernen Delphi-Versionen ist Unicode Standard. Die FireDAC-Kette (Client-Library, Connection-Optionen, DB-Collation, Feldtypen) muss konsistent sein, sonst drohen Zeichen- und Vergleichsprobleme.
- Deployment: Je nach DB werden Client-Bibliotheken benötigt (z. B. libpq für PostgreSQL). Das muss früh geplant werden, sonst entstehen produktionsnahe Überraschungen.
Zielbild für eine FireDAC-Architektur: stabil, testbar, erweiterbar
Eine BDE-Ablösung sollte nicht in „FireDAC überall irgendwie“ enden. Ein tragfähiges Zielbild ist besonders dann wertvoll, wenn die Anwendung weiterentwickelt oder in Services/Portale eingebettet werden soll.
Minimalziel: einheitlicher Connection-Layer
Statt verteilter Verbindungen in Formularen empfiehlt sich ein zentraler Connection-Layer:
- Erzeugung und Konfiguration von TFDConnection an einer Stelle
- Einheitliche Timeouts, Encoding/CharacterSet, Fehlerhandling
- Umschaltung Dev/Test/Prod ohne manuelle Nacharbeit
- Optional: zentrale Aktivierung von Tracing/Monitoring für Diagnosefälle
Empfohlen: klare Transaktionsgrenzen in der Fachlogik
Viele Altanwendungen verteilen Datenänderungen über UI-Events. Das erhöht das Risiko von Teilupdates und erschwert Tests. Ein stabiler FireDAC-Ansatz ist: Der Use Case (Service/Fachlogik) startet und beendet die Transaktion, nicht die UI. Auch bei einer reinen VCL-Desktopsoftware entsteht so ein robuster Kern, der später leichter als Service oder API nutzbar ist.
Erweiterungsfähig Richtung Services und REST
Wer später einen REST-Server ergänzt, Windows- oder Linux-Services betreibt oder ein Kundenportal anbinden will, profitiert von einem sauberen Datenlayer. FireDAC ist dafür geeignet, wenn Connection-Management, Fehlerbehandlung und – je nach Server-Last – Pooling zumindest als Zielbild mitgedacht werden. Das muss nicht im ersten Schritt umgesetzt sein, sollte aber die Architektur nicht blockieren.
Migrationsstrategie: FireDAC schrittweise einführen, BDE kontrolliert zurückbauen
In B2B-Umgebungen ist ein Big Bang selten realistisch: zu viele Fachprozesse, zu viel Betriebsverantwortung, zu wenig Akzeptanz für lange Downtimes. Eine schrittweise BDE-Ablösung ist in der Regel der sichere Weg.
Phase 1: Bestandsaufnahme und Risikokarte
Eine brauchbare Inventur zählt nicht nur Komponenten, sondern bewertet Verhalten und Kopplungen:
- Welche Datenbank(en) werden genutzt: Paradox/dBase, Firebird/InterBase, SQL Server, PostgreSQL, MariaDB?
- Wo hängen TTable-Zugriffe, wo wird SQL per TQuery genutzt, wo Stored Procedures?
- Wie werden Transaktionen heute gelebt (explizit, implizit, Cached Updates, gemischte Muster)?
- Welche Reports/Exports erwarten bestimmte Dataset-Eigenschaften (Sortierung, Filter, Calculated Fields)?
- Welche Drittkomponenten oder Eigenframeworks sind BDE-spezifisch?
Aus dieser Karte ergibt sich, ob die Ablösung „nur“ den Zugriff betrifft oder ob parallel ein Datenbank-Umbau (z. B. Paradox → SQL Server/PostgreSQL/MariaDB) sinnvoll oder zwingend ist.
Phase 2: FireDAC-Foundation (ohne UI-Umstellung)
Bevor Sie Screens migrieren, sollte FireDAC technisch sauber stehen:
- Zentrales DataModule oder Service-Klasse mit TFDConnection
- Konfigurationsmodell für Connection Strings (z. B. INI/JSON) und saubere Secrets-Verwaltung
- Standardisierte Fehlerbehandlung (DB-Exceptions in verständliche, logbare Meldungen überführen)
- Tracing/Monitoring-Optionen für Pilotbetrieb (gezielt aktivierbar, nicht dauerhaft „laut“)
Wichtig ist, dass daraus verbindliche Standards entstehen: Namenskonventionen, Parameterregeln, Logging-Schema, Default-Einstellungen pro Datenbank.
Phase 3: Pilotmodul mit echter Fachrelevanz
Ein guter Pilotbereich ist fachlich abgegrenzt, aber real genutzt. Ziel: Muster entwickeln und verifizieren.
- TQuery → TFDQuery (inkl. Parameterisierung und Typisierung)
- Transaktionsrahmen definieren und im Code sichtbar machen
- Ergebnisgleichheit nachweisen (fachlich relevante Resultsets vergleichen)
- Performance messen (Antwortzeiten, DB-Last, Netzwerkverkehr)
Am Ende des Piloten sollte eine interne Checkliste stehen, nach der jedes weitere Modul migriert wird. Das senkt Risiko und macht Aufwand planbarer.
Phase 4: Flächenmigration und Deployment-Bereinigung
Nach dem Pilot wird nach Modulen umgestellt. Parallel wird die BDE als Betriebsabhängigkeit zurückgebaut:
- Installer-Skripte und Dokumentation von BDE-Setups entfernen
- Alias-Definitionen, NetDir-Konfiguration und Sonderpfade eliminieren
- Build-/Release-Pipeline auf neue Abhängigkeiten (Client-Libs, Treiber) ausrichten
Gerade dieser Rückbau ist essenziell: Solange BDE-Teile im Deployment überleben, bleibt das Betriebsrisiko bestehen.
Stolperstellen: häufige Ursachen für fachliche Seiteneffekte
Viele Migrationen scheitern nicht an FireDAC, sondern an impliziten Annahmen im Altcode. Diese Bereiche sollten Sie früh priorisieren.
SQL-Dialekte und historisch gewachsenes SQL
BDE-Anwendungen enthalten häufig SQL, das mit einem bestimmten Treiber „zufällig“ funktionierte: implizite Joins, uneinheitliche Alias-Nutzung, DB-spezifische Funktionen, unklare Sortierungen. In der Migration gilt:
- SQL explizit machen (JOIN-Syntax statt impliziter WHERE-Verknüpfung)
- Reserved Words und Identifier prüfen (z. B. DATE, USER, ORDER als Feldnamen)
- Datums-/Zeit- und Stringfunktionen vereinheitlichen oder kapseln
FireDAC bietet Anpassungsmöglichkeiten, aber die nachhaltig richtige Lösung ist DB-konformes, gut lesbares SQL.
Datentyp-Mapping: Boolean, Datum/Zeit, Memo/Blob, NULL
Die BDE hat in der Praxis viel interpretiert. FireDAC ist präziser – was gut ist, aber Regeln verlangt. Typische Themen:
- Boolean: BIT/SMALLINT/CHAR(1) – fachlich klar definieren, keine impliziten Konvertierungen
- Datum/Zeit: DATETIME vs. DATETIME2, Millisekunden, Sortier-/Vergleichslogik; Zeitzonenfragen bei verteilten Systemen
- Memo/Blob: Fetch-Verhalten (OnDemand), Encoding, Speicherverbrauch im Client
- NULLability: Altcode, der leere Strings und NULL vermischt, führt zu schwer sichtbaren Logikfehlern
Bewährt hat sich ein schlanker Datentyp-Katalog: pro fachlich wichtiger Tabelle/Spalte Zieltypen (DB und Delphi) plus Regeln für NULL, Defaultwerte und Formatierungen.
Transaktionen: von implizit zu bewusst orchestriert
In Legacy-Delphi-Projekten ist ein häufiger Fehler, dass das System sich auf implizite Commits verlassen hat („wenn ich das Dataset schließe, ist es gespeichert“). FireDAC bietet klare APIs (StartTransaction, Commit, Rollback). Der Modernisierungsvorteil entsteht, wenn Transaktionen als fachlicher Rahmen verstanden werden:
- Use Case startet Transaktion
- Mehrere Updates laufen innerhalb derselben Connection
- Commit/Rollback erfolgt zentral mit nachvollziehbarem Error-Handling
Das reduziert Inkonsistenzen und ist entscheidend, wenn die Anwendung später um Services oder Schnittstellen ergänzt wird.
Cached Updates und Konfliktbehandlung (Concurrency)
Viele BDE-Anwendungen nutzen Cached Updates als „Offline-Edit“-Mechanik. FireDAC kann Ähnliches, aber die Regeln müssen explizit werden:
- Welche Felder sind Schlüssel, welche dienen der Concurrency-Prüfung?
- Wie werden Konflikte aufgelöst (RowVersion/Timestamp, „last write wins“, Benutzerentscheidung)?
- Was passiert bei Teilfehlern in Batch-Operationen?
In Modernisierungen ist es oft sinnvoll, die Konfliktlogik näher an die Fachlogik oder in eine Service-Schicht zu ziehen, statt sie ausschließlich im UI-Dataset-Verhalten zu verstecken.
TTable/Paradox-lastige Anwendungen: FireDAC ist nicht die einzige Baustelle
Wenn die Anwendung stark auf dateibasiertem Zugriff beruht (TTable gegen Paradox), ist „BDE durch FireDAC“ nur ein Teil der Wahrheit. FireDAC ist primär für SQL-Datenbanken gedacht. Dann ist die zentrale Entscheidung: Wird die Datenhaltung auf eine Server-DB modernisiert?
- Migration nach SQL Server, PostgreSQL oder MariaDB
- Einführung eines Rollen-/Rechtekonzepts und sauberer Backup/Restore-Prozesse
- Stabiler Mehrbenutzerbetrieb ohne Datei-Locking-Probleme
Falls ein sofortiger Datenbankwechsel organisatorisch nicht möglich ist, ist ein zweistufiges Vorgehen oft pragmatisch: erst Zugriffsschicht stabilisieren und UI-Kopplung reduzieren, dann Datenmigration mit klarer Test- und Cutover-Strategie.
Reporting, Exporte und Drittkomponenten
Reports hängen häufig an Details: Sortierungen, Filterreihenfolgen, berechnete Felder, Master/Detail-Verhalten. Für eine kontrollierte Umstellung:
- kritische Reports identifizieren und als Regressionstest-Suite behandeln
- Datensätze für Reports deterministisch erzeugen (Views/Stored Procedures oder klar definierte Queries)
- UI-seitige Filterketten reduzieren, die vom Datasetverhalten abhängen
Das Ziel ist reproduzierbare Ergebnisgleichheit, gerade bei auditrelevanten Auswertungen.
Architektur-Upgrade im Zuge der FireDAC Migration: pragmatisch entkoppeln
Die BDE-Ablösung ist ein guter Zeitpunkt, den Datenzugriff aus Formularen und Eventhandlern herauszuholen. Das bedeutet nicht, dass ein komplettes Re-Architecture-Projekt nötig ist. Schon moderate Maßnahmen bringen oft große Wirkung.
Pragmatische Zielstruktur (anschlussfähig an Layer-3-Architektur)
- Connection/Unit-of-Work: verwaltet Connection und Transaktion, stellt Query-Objekte bereit
- Repository/DAO: kapselt SQL und Datenzugriff pro fachlichem Bereich
- Service/Use Case: orchestriert Fachlogik, Validierungen und Transaktionsrahmen
Diese Struktur ist kompatibel mit einer späteren Layer-3 Architektur und erleichtert Folgeprojekte: REST-Schnittstellen, Hintergrundservices, Multiplattform-Clients oder die Kopplung an Portale.
Wichtiger Effekt: weniger globale Seiteneffekte
Viele BDE-Projekte arbeiten mit globalen Datenmodulen und impliziten Zuständen. FireDAC funktioniert auch so, aber die Modernisierung wird stabiler, wenn Zustände lokalisiert werden: klarer Lebenszyklus von Connection/Transaktion, reproduzierbare Fehlerpfade, weniger „Nebenwirkungen“ durch globalen Zustand.
Performance und Stabilität: FireDAC gezielt konfigurieren
FireDAC ist leistungsfähig, aber Performance ist eine Kombination aus SQL, Indexing, Fetch-Strategie und Connection-Management. In Migrationen zeigt sich häufig: Die BDE hat ineffiziente Muster überdeckt, weil Datenmengen früher kleiner waren oder weil das System lokal lief.
Fetch-Strategien und UI-Listen
- Listen laden nur benötigte Spalten (kein SELECT *)
- Serverseitige Sortierung und gezielte Filter statt clientseitiger Ketten
- Bei großen Datenmengen: Paging oder inkrementelles Nachladen
- LOB-Felder (Memo/Blob) erst laden, wenn wirklich benötigt
FireDAC bietet hierfür passende Optionen; entscheidend ist die fachliche Entscheidung, welche Daten ein Anwender im jeweiligen Kontext tatsächlich braucht.
Prepared Statements und Parametrisierung
Parametrisierte Queries sind nicht nur Sicherheitsstandard (SQL-Injection vermeiden), sondern verbessern in vielen Datenbanken die Plan-Wiederverwendung. Zusätzlich wird Typunsauberkeit im Altcode sichtbar und kann gezielt korrigiert werden. Gerade in gewachsenen Systemen ist das ein Qualitätsgewinn, der sich in weniger Sonderfällen und besserer Diagnostik auszahlt.
Connection-Management: Desktop vs. Service/REST
In klassischen Desktop-Clients ist oft eine langlebige Connection pro Client praktikabel. In Services oder REST-Servern sind andere Muster üblich: kurzlebigere Requests, parallele Zugriffe, Connection-Pooling. Wer die BDE-Ablösung als Teil einer größeren Modernisierung sieht, sollte diese Unterschiede im Zielbild berücksichtigen, damit spätere Ausbaustufen nicht am Datenzugriff neu beginnen müssen.
Test- und Abnahmestrategie: Ergebnisgleichheit nachweisen
Bei der BDE-Ablösung ist das Hauptrisiko selten „die Anwendung startet nicht“, sondern leise fachliche Abweichungen: Sortierungen, Rundungen, NULL-Handling, Transaktionsgrenzen, Nebenwirkungen von Triggern/Constraints in modernen DBs. Eine tragfähige Teststrategie umfasst:
- SQL-Regression: kritische Abfragen gegen definierte Testdaten ausführen und Ergebnissets vergleichen
- Use-Case-Tests: Kernprozesse (z. B. Buchen, Freigeben, Storno, Import/Export) mit Erwartungswerten prüfen
- Mehrbenutzer-/Stabilitätstests: Sperrverhalten, Deadlocks, Timeouts, Transaktionsdauer
- Logging/Observability: DB-Fehler strukturiert erfassen (Fehlercodes, Kontext, betroffene Query), nicht nur „Fehlerdialog“
Unternehmen profitieren hier doppelt: Die Tests sichern die Migration ab und schaffen eine Grundlage, um spätere Änderungen am Datenmodell oder an Schnittstellen kontrolliert auszurollen.
Zieldatenbanken in FireDAC-Projekten: typische Optionen
FireDAC ist bewusst breit, aber jede Datenbank bringt eigene Regeln. In Modernisierungen sind folgende Ziele häufig:
SQL Server
Typisch in Windows-dominierten IT-Landschaften. Wichtige Punkte: konsistente Unicode-Typen (NVARCHAR), moderne Zeittypen (DATETIME2), klare Identity-/Sequence-Strategie, definierte Isolation Levels und ein sauberer Umgang mit Sperren.
PostgreSQL
Stark bei Integrität und Features. In Migrationen relevant: Identifier-Case-Sensitivity, Datentypen (boolean/uuid/jsonb) und Dialektunterschiede. FireDAC kann PostgreSQL produktiv anbinden, wenn Client-Libraries und Deployment sauber organisiert sind.
MariaDB/MySQL
Häufig, wenn Desktopsoftware mit Web- oder Portal-Komponenten zusammenspielt. Wichtig: utf8mb4 konsequent, InnoDB als Engine, saubere Transaktions- und Indexstrategie. FireDAC unterstützt MariaDB/MySQL zuverlässig, wenn Parameter und Typen klar definiert sind.
Unabhängig vom Ziel gilt: Eine BDE-Ablösung wird am stabilsten, wenn parallel Datenbank-Standards entstehen (Schema-Versionierung, Migrationsskripte, Rollen/Rechte, Backup/Restore, Monitoring).
Praxisempfehlungen für eine planbare FireDAC Migration
Abhängigkeiten reduzieren, bevor Sie in Masse Komponenten tauschen
Wenn SQL und Dataset-Logik in vielen Formularen stecken, wird jede Änderung teuer. Ein Zwischenschritt, der SQL in wenige Zugriffsklassen bündelt, reduziert die Migrationsfläche deutlich. Danach ist die eigentliche Umstellung auf FireDAC oft schneller und risikoärmer.
Früh einen transaktionalen Kernprozess migrieren
„Einfache Listen“ sind als Einstieg bequem, aber risikoreduzierend ist es, früh einen Prozess mit echten Updates und Abhängigkeiten zu migrieren. Wenn Transaktionen, Datentypen und Fehlerpfade dort sauber sind, wird die restliche Migration planbarer.
Deployment als gleichrangige Arbeit behandeln
Die Code-Umstellung ist nur die halbe Miete. Klären Sie früh:
- Welche Client-Libraries/Treiber werden pro Datenbank benötigt?
- Wie werden diese versioniert, signiert (falls relevant) und ausgerollt?
- Wie werden Connection-Parameter verwaltet, und wer darf sie ändern?
- Wie sieht der Supportprozess aus, wenn DB-Zugriffe fehlschlagen?
FireDAC als Modernisierungsanker nutzen – ohne Neuanfang
Die Ablösung ist eine Gelegenheit für gezielte Qualitätshebel: Parametrisierung, Transaktionsgrenzen, Logging, einheitliche Fehlertexte. Das reduziert Betriebskosten und macht spätere Erweiterungen (Schnittstellen, Services) deutlich risikoärmer, ohne die Anwendung fachlich neu zu erfinden.
Fazit: BDE-Ablösung mit FireDAC ist kontrollierbare Modernisierung – wenn sie als Architekturthema behandelt wird
Die BDE hat viele Delphi-Anwendungen über Jahre getragen. Heute ist sie jedoch ein strukturelles Risiko: für 64‑Bit, für standardisiertes Deployment, für moderne Security-Anforderungen und für den Anschluss an zeitgemäße Datenbanken. FireDAC ist der passende Nachfolger, aber nicht als „Komponententausch über Nacht“. Die sichere Route ist eine schrittweise Migration mit sauberer Foundation, Pilotmodul, verbindlichen Regeln für Datentypen und Transaktionen sowie Tests, die Ergebnisgleichheit nachweisen.
Wenn Sie die BDE-Ablösung strukturiert planen möchten – inklusive Bestandsanalyse, Migrationspfad und FireDAC-Zielarchitektur – ist ein technischer Abgleich Ihrer Rahmenbedingungen der sinnvollste nächste Schritt: https://net-base-software-gmbh.de/kontakt/