Es ruft jemand an, der eine KHK Classic Line aus den Nullerjahren im Keller stehen hat. Der Sage-Partner von damals ist in Rente, die Wartung längst gekündigt, und jetzt will der Steuerberater die Buchungsdaten von vor acht Jahren sehen. Jemand aus der IT hat schon versucht, die Dateien mit einem Tool zu öffnen — und nur Buchstabensalat gesehen.
Das ist kein Bedienfehler. Es liegt daran, dass an vielen Stellen im Netz steht, KHK Classic sei eine „dateibasierte dBASE-Lösung, die man einfach mit Access oder einem DBF-Viewer aufmacht“. Das stimmt nicht. Und wer sich darauf verlässt, verliert Tage.
Was unter der KHK Classic wirklich liegt
KHK Classic Line, später als Sage Classic Line und Sage New Classic vermarktet, ist eine ERP- und Fibu-Lösung, die ab 1983 entstand und in kleinen und mittleren Betrieben jahrzehntelang lief. Die Anwendung selbst wurde in Delphi beziehungsweise Borland Pascal geschrieben. Das Entscheidende ist die Datenhaltung darunter: KHK Classic speichert ihre Daten in Btrieve beziehungsweise Pervasive.SQL — heute heißt diese Engine Actian Zen.
Btrieve ist keine relationale Datenbank im üblichen Sinn. Es ist ein transaktionaler ISAM-Speicher, der Datensätze als reine Byte-Folgen ablegt. In der Fachliteratur heißt das wörtlich, die Daten lägen als „bag of bits“ vor — ohne mitgespeicherte Information darüber, wo ein Feld anfängt, wie lang es ist und was es bedeutet.
Genau deshalb scheitert der naive Zugriff. Ein DBF-Viewer oder ein direkter Access-Import sieht nur die rohe Byte-Folge. Ohne eine externe Beschreibung der Struktur ist daraus nichts Lesbares zu machen.
Der Schlüssel heißt DDF, nicht DBF
Damit aus den Byte-Folgen lesbare Tabellen werden, braucht die Pervasive-Engine ein Daten-Dictionary: die sogenannten DDF-Dateien, typischerweise FILE.DDF, FIELD.DDF und INDEX.DDF. Diese Dateien beschreiben, welche Btrieve-Datei welcher Tabelle entspricht, welche Felder es gibt, wo sie liegen und welchen Datentyp sie haben.
Erst mit gültigen DDF-Dateien plus installierter Pervasive- beziehungsweise Actian-Zen-Engine lässt sich überhaupt ein ODBC-Zugriff einrichten. Liegen die DDFs nicht vor oder zeigt die ODBC-Datenquelle auf den falschen Pfad, kommt nur eine Fehlermeldung zurück — der berüchtigte „Btrieve Error 35″, wenn das Dateiverzeichnis nicht stimmt.
Ein zweiter Stolperstein ist die Verschlüsselung. Btrieve-Dateien können mit einem sogenannten Owner Name versehen sein — faktisch ein Passwort auf Dateiebene, das den Zugriff sperrt oder die Datei verschlüsselt. Ist ein Owner Name gesetzt und nicht bekannt, hilft auch die schönste DDF nichts. Das ist exakt das Szenario, das Anrufer als „die Daten sind verschlüsselt“ beschreiben.
Die ehrliche Reihenfolge der Zugriffswege
Aus der Praxis im norddeutschen Mittelstand hat sich diese Reihenfolge bewährt — vom einfachsten zum härtesten Fall.
Weg 1 — Export aus der laufenden Anwendung. Solange die KHK Classic noch startet und eine Lizenz vorhanden ist, ist das der mit Abstand sauberste Weg. Die Software bringt eigene Export- und Listenfunktionen mit, die Fibu kann nach DATEV exportieren, Stammdaten lassen sich als Datei ausgeben. Diese Exporte sind strukturiert und brauchen kein Reverse Engineering. Wenn irgend möglich: diesen Weg nehmen, bevor das System endgültig abgeschaltet wird.
Weg 2 — ODBC über die Pervasive-/Actian-Zen-Engine. Wenn die Engine läuft, die DDF-Dateien vorhanden und die Owner Names bekannt (oder nicht gesetzt) sind, lässt sich eine ODBC-Datenquelle einrichten. Darüber kommt man dann entweder per Linked Server aus dem SQL Server heran oder per verknüpfter Tabelle aus Access.
Das hier ist der Kern des SQL-Server-Zugriffs über einen Linked Server auf die Pervasive-ODBC-Quelle:
-- Linked Server "KHK_PSQL" zeigt auf die Pervasive-/Actian-Zen-ODBC-Datenquelle.
-- Voraussetzung: gültige DDFs, laufende Engine, bekannter Owner Name.
SELECT *
FROM OPENQUERY(KHK_PSQL,
'SELECT "KU_NR", "KU_NAME", "KU_ORT" FROM "Kunden"');
Der entscheidende Punkt ist nicht die Syntax, sondern die Feldnamen: In Classic-Line-DDFs heißen Felder oft kryptisch oder historisch gewachsen. Ohne Doku oder den alten Entwickler bleibt das Zuordnen der Felder zu ihrer Bedeutung Handarbeit.
Weg 3 — Export-Datei nach SQL Server oder Access laden. Hast du über Weg 1 oder 2 eine CSV gezogen, ist der Rest Routine. In den SQL Server geht das per BULK INSERT:
BULK INSERT dbo.KHK_Kunden
FROM 'D:\khk_export\kunden.csv'
WITH (
FIELDTERMINATOR = ';',
ROWTERMINATOR = '0x0a',
FIRSTROW = 2,
CODEPAGE = '1252' -- alte KHK-Exporte sind meist Windows-1252, nicht UTF-8
);
Der CODEPAGE-Hinweis ist hier kein Detail: Alte KHK-Exporte kommen fast nie als UTF-8. Wer das übersieht, bekommt zerschossene Umlaute und sucht den Fehler stundenlang an der falschen Stelle.
Wo der Weg endet
Wenn die KHK Classic nicht mehr startet, die Engine fehlt, die DDF-Dateien verschwunden sind oder ein unbekannter Owner Name die Dateien sperrt, wird es ehrlich gesagt schwierig. Dann bleibt nur das Reverse Engineering der rohen Btrieve-Dateien — Byte-Layouts rekonstruieren, Datensatzlängen ermitteln, Felder raten und gegen bekannte Werte prüfen. Das funktioniert oft teilweise, selten vollständig und nie schnell.
Deshalb der wichtigste Satz dieses Artikels: Solange die alte KHK noch irgendwo startet, ist das ein gutes Zeichen. Genau dann lohnt es sich, die Daten geordnet herauszuholen, statt zu warten, bis der letzte Rechner mit der Engine endgültig den Geist aufgibt.
Eine Randnotiz noch zur Abgrenzung, weil sie regelmäßig für Verwirrung sorgt: KHK hatte zwei Linien. Die Classic Line läuft auf Btrieve/Pervasive — um die geht es hier. Die Office Line dagegen setzte auf den Microsoft SQL Server und ging später in Sage 100 über. Wer eine Office Line hat, ist in einer deutlich komfortableren Lage, weil dort von Haus aus eine relationale Datenbank unter der Anwendung liegt.
Was das für dich heißt, wenn du es nicht selbst baust
Sage hat die New Classic bereits 2016 abgekündigt, der offizielle Migrationspfad ist Sage 100. Für dich als Geschäftsführer bedeutet das zweierlei. Erstens: Die Daten in einer alten Classic Line sind nicht „weg“, aber sie sind hinter einer Technik eingeschlossen, die kaum noch jemand bedient. Zweitens: Der Aufwand, da heranzukommen, hängt fast vollständig davon ab, ob das System noch läuft und ob die Engine und die DDF-Dateien noch greifbar sind.
Wer eine Betriebsprüfung, eine Auswertung über mehrere Jahre oder eine Migration vor sich hat, sollte das nicht auf die lange Bank schieben. Der Unterschied zwischen „die Software startet noch“ und „der Rechner ist seit zwei Jahren abgeschaltet“ ist der Unterschied zwischen einem überschaubaren Export und einem teuren Rettungsprojekt mit ungewissem Ausgang.
Wenn du sowas im Bestand hast
Wenn bei euch noch eine KHK Classic oder Sage Classic Line steht und ihr an die Daten müsst — für eine Auswertung, eine Prüfung oder eine geordnete Ablösung — dann schau dir den Stand an, solange die Software noch startet. Wer das einmal von jemandem prüfen lassen möchte, der Btrieve-Altbestände kennt, erreicht mich über ein kostenloses Erstgespräch.
Quellen
- Classic Line, Produktgeschichte und Datenbankdienst: Wikipedia – Classic Line
- Btrieve-Datenzugriff und DDF-Dateien (White Paper, Goldstar Software): Accessing Zen/PSQL Data From ODBC
- Owner Names und FILE.DDF-Struktur: Experts Exchange – Pervasive DDF auslesen
- Btrieve Error 35 und DDF-Pfad: Sage Intelligence Knowledgebase
Über Sönke Schäfer
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung und Datenrettung aus gewachsenen Branchen- und ERP-Systemen. Sein Schwerpunkt liegt darauf, Daten aus Altsystemen wie KHK, Btrieve und proprietären Formaten strukturiert nach SQL Server oder Microsoft Access zu überführen — ohne übereilten ERP-Wechsel, dort wo der Bestand sich noch retten lässt. Büro in Sierksdorf, Ostholstein.