Fremde Leute rufen mich an. Jemand hat ihnen erzählt, büro+ laufe auf SQL Server, man könne einfach per ODBC rein. Jetzt stehen sie vor einer Datenbank, die sich nicht öffnen lässt. Das ist kein Einzelfall — es ist ein Missverständnis, das mit der Version beginnt.
Welche büro+-Version läuft bei dir?
Das ist die erste Frage, und die Antwort bestimmt alles weitere.
büro+ bis Version L / älter (Enterprise-Server): Die Daten liegen in einem proprietären Format, das microtech selbst entwickelt hat — in Delphi geschrieben, eigener Caching-Mechanismus, kein SQL Server dahinter. Kein SSMS, kein ODBC, kein direkter Datenbankzugriff von außen. Externer Zugriff läuft ausschließlich über die COM-Aktiv-Schnittstelle, solange büro+ läuft und eine gültige Lizenz vorhanden ist.
büro+ ab Version M (mit SQL Server Backend): Hier liegt eine echte Microsoft SQL Server-Datenbank dahinter. ODBC-Zugriff funktioniert, Access und Power BI können direkt verknüpft werden, T-SQL-Abfragen laufen durch. Das ist der Fall, den viele im Kopf haben, wenn sie über büro+-Anbindung reden.
büro+ plus.6 (aktuelle Generation): SQL Server als Backend, zusätzlich eine Web-API für moderne Integrationen. SQL-Replikation nach PostgreSQL ist offiziell dokumentiert und unterstützt.
Wenn du nicht weißt, welche Version läuft: in büro+ unter Hilfe → Info nachschauen, oder den IT-Dienstleister fragen, der das damals installiert hat.
Daten aus büro+ rausziehen: Die vier Wege
Weg 1: Direkter SQL-Zugriff (nur Version M+)
Wenn SQL Server dahinter liegt, geht das am saubersten. ODBC-DSN einrichten, Readonly-User anlegen, fertig. Access kann die Tabellen verknüpfen, Power BI kann direkt abfragen, SSIS kann exportieren.
Typische Tabellen, die du brauchst:
| Tabelle | Inhalt |
|---|---|
| ADRESSE | Kunden, Lieferanten |
| ARTIKEL | Artikelstamm |
| AUFTRAG_KOPF | Aufträge, Belege |
| AUFTRAG_POS | Positionen |
| RECHNUNG_KOPF | Rechnungen |
| BUCHUNG | FiBu-Buchungen |
Das funktioniert — aber nur für Version M und neuer. Wer das einem Kunden mit Enterprise-Server-Version empfiehlt, sitzt auf einem falschen Versprechen.
Weg 2: COM-Aktiv-Schnittstelle (alle Versionen, büro+ muss laufen)
microtech stellt eine COM-Schnittstelle bereit, über die Daten programmatisch abgerufen werden können. VBA mit Microsoft Access, C#, Delphi — alles möglich. Die Schnittstelle heißt COM-Aktiv, der COM-Server läuft als BpNext.exe.
Die Einschränkung: microtech gibt nur bestimmte Felder für den COM-Zugriff frei. Was nicht freigegeben ist, siehst du nicht. Das ist keine Lücke, das ist Absicht. Wer schreibenden Zugriff braucht, kommt ebenfalls über COM-Aktiv rein — aber auch nur auf die freigegebenen Objekte.
COM-Aktiv ist der einzige offizielle Weg für alle Versionen ohne SQL Server Backend.
Weg 3: ADO-Export aus büro+ heraus (alle Versionen)
büro+ kann selbst Daten nach außen schieben — in SQL Server, Access, Excel, oder über ODBC. Das konfigurierst du über Export-Layouts und Automatisierungsaufgaben innerhalb von büro+. Kein Pull von außen, sondern ein Push, den büro+ selbst steuert.
Für regelmäßige, geplante Exporte brauchbar. Für ad-hoc-Abfragen ungeeignet — du kannst nicht einfach eine spontane Frage an die Datenbank stellen.
Weg 4: Fertigtools nutzen — besser ein brauchbarer Standard als eine neue Bastellösung
Für den Enterprise-Server-Fall gibt es zwei etablierte Drittanbieter-Werkzeuge, die genau das Problem lösen:
BPBackup2SQL (compusoft-fn.de): Läuft als Dienst, zieht per COM-Aktiv alle freigegebenen Felder aus büro+ und schreibt sie in eine SQLite-Datenbank. Inkrementell, spiegelt auch Löschungen, wandelt RTF-Felder in HTML um. Der Haken: SQLite ist kein SQL Server. Wer Access oder Power BI direkt anbinden will, braucht entweder einen ODBC-Treiber für SQLite oder einen zusätzlichen Sync-Schritt.
SF BP Sync (ct-systeme.com): Macht dasselbe, schreibt aber direkt in SQL Server. Für eine Datendrehscheibe auf SQL Server-Basis ist das der sauberere Weg — kein SQLite-Umweg, direkter Anschluss an bestehende BI- und Access-Infrastruktur.
Meine Empfehlung: Wer bereits einen SQL Server betreibt, sollte SF BP Sync dem Eigenbauprojekt vorziehen. Eine COM-Aktiv-Anbindung selbst zu stricken ist machbar — aber du pflegst dann dauerhaft Code, der von microtech-Updates abhängt.
Daten in büro+ reinschreiben
Die meisten Anfragen gehen ums Lesen. Aber manchmal soll auch geschrieben werden — Artikelstammdaten aus einem anderen System, Kundenadressen synchronisieren, Auftragspositionen aus einem Webshop übernehmen.
Für Version M+ (SQL Server): direktes Schreiben in die Tabellen ist technisch möglich, aber risikobehaftet. microtech dokumentiert das Datenmodell nicht vollständig, und Updates können die Tabellenstruktur verändern. Schreibender Zugriff läuft besser über COM-Aktiv oder — wo vorhanden — über die offizielle Import-Schnittstelle von büro+ selbst.
Für den Enterprise-Server gilt dasselbe: COM-Aktiv ist der Weg, direkte Dateimanipulation ist kein Weg.
Der blinde Fleck: Was passiert, wenn büro+ nicht mehr startet?
Hier ist der Punkt, der in vielen Gesprächen fehlt.
Wenn büro+ nicht mehr startet — weil die Lizenz abgelaufen ist, der Anbieter-Server weg ist, der Betreiber insolvent wurde, oder schlicht weil ein Update etwas gebrochen hat — kommst du an die proprietären Datenbankdateien ohne microtech-Support nicht ran. Die Dateien sind da. Du kannst sie nicht öffnen.
Das ist kein theoretisches Szenario. microtech-Kunden, die auf eine ältere Version eingefroren sind und deren Reseller den Betrieb eingestellt hat, stehen genau vor diesem Problem.
Das ist kein Vorwurf an microtech. Jede Software mit proprietärem Datenbankformat hat dieses Risiko. Aber es ist ein Vendor-Lock-in, den man kennen und aktiv adressieren muss.
Der richtige Umgang damit: Eine laufende Datensicherung außerhalb des büro+-Formats, bevor das System steht. Genau dafür existieren Tools wie BPBackup2SQL — die sichern im laufenden Betrieb per COM-Aktiv in ein offenes Format, auf das man auch ohne büro+ zugreifen kann. Wer das nicht eingerichtet hat, setzt auf Vertrauen in einen einzelnen Anbieter. Das ist ein Risiko, das sich mit überschaubarem Aufwand vermeiden lässt.
Aus meiner Praxis: Der Anlass für diese Einrichtung ist fast immer reaktiv — nach einem Problem, nicht davor. Wer es proaktiv macht, schläft ruhiger.
Zusammenfassung: Welchen Weg wählen?
| Situation | Empfehlung |
|---|---|
| büro+ Version M+ mit SQL Server | ODBC/Linked Server, direkte T-SQL-Abfragen |
| büro+ Enterprise-Server, SQL Server vorhanden | SF BP Sync → direkte SQL Server-Replikation |
| büro+ Enterprise-Server, kein SQL Server | BPBackup2SQL → SQLite, ODBC für Access/BI |
| Schreibender Sync | COM-Aktiv oder offizieller büro+-Import |
| büro+ startet nicht mehr | Zu spät — microtech-Support, Datenverlustrisiko |
Die schlechte Nachricht: „Einfach per ODBC rein“ gilt nur für eine Minderheit der Installationen da draußen. Die gute Nachricht: Für den Rest gibt es fertige Werkzeuge, die du nicht selbst bauen musst.
Wer sich das für seine büro+-Installation konkret anschauen möchte — welche Version läuft, welcher Weg passt — kann mich über sesoft.de/kostenloses-erstgespraech-sichern erreichen.
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung von Branchensoftware an SQL Server und Microsoft Access. Sein Schwerpunkt liegt auf pragmatischen Datendrehscheiben rund um Altsysteme — ohne ERP-Wechsel, ohne Neuentwicklung, wo es sich vermeiden lässt. Er arbeitet von Sierksdorf in Ostholstein aus, hauptsächlich für den norddeutschen Mittelstand.
Quellen
- microtech Hilfe – COM-Aktiv-Schnittstelle: hilfe.microtech.de
- microtech Hilfe – ADO Import/Export: hilfe.microtech.de/pages/viewpage.action?pageId=11735132
- microtech Hilfe – SQL-Replikation: hilfe.microtech.de/04_moduluebergreifend/sql-replikation/
- BPBackup2SQL: compusoft-fn.de/bpbackup2sql-datensicherung-fuer-buero/
- SF BP Sync: ct-systeme.com/SFBPSync/