Ein Controller will die Umsätze über fünf Jahre auswerten und nicht jedes Mal über „Exportieren nach Excel“ gehen. Die IT sagt: „Kein Problem, die WinLine liegt auf SQL Server, ich häng mich per ODBC dran.“ Eine Stunde später kommt der Rückruf. Es gibt nicht eine Datenbank, sondern drei. Und die Tabellen heißen nicht Kunden oder Artikel, sondern T009 und T220CMP.
Das ist kein Fehler in der Installation. Es ist die normale Realität bei Mesonic WinLine. Und es ist der Grund, warum der gut gemeinte Rat „häng dich einfach an den SQL Server“ in der Praxis nicht weit trägt.
Was unter der WinLine wirklich liegt
Mesonic WinLine ist ein modulares ERP-System aus Österreich, im deutschsprachigen Raum seit den 90ern verbreitet. Anders als manche andere Altsysteme liegt darunter tatsächlich eine relationale Datenbank. Nur eben nicht zwingend die, die man erwartet.
WinLine kennt mehrere Backends, abhängig von Ausbaustufe und Alter der Installation. Standard im Mittelstand ist der Microsoft SQL Server beziehungsweise die mitgelieferte MSDE oder SQL Server Express, oft mit der Instanz \MESONIC. Daneben unterstützt WinLine ausdrücklich PostgreSQL. In der Corporate-Ausbaustufe kommen größere SQL-Datenbanken bis hin zu Oracle vor. Und ältere Datenstände, vor der SQL-Umstellung, liefen auf einem DAO/MDB-Backend — also einer Jet-Datei, wie Access sie nutzt.
Die erste Frage bei jedem WinLine-Zugriff lautet deshalb nicht „wie komme ich rein“, sondern „was liegt überhaupt drunter“. Ein Satz, der das im alten Beitrag pauschal mit „Microsoft SQL Server“ beantwortet hat, führt bei einer PostgreSQL- oder einer alten MDB-Installation direkt in die Irre.
Drei Datenbanken, kodierte Tabellen, eine Landkarte
Selbst wenn ein SQL Server drunterliegt, ist die Arbeit damit nicht getan. WinLine speichert jeden Mandanten in einer eigenen Datenbank und trennt davon die Systemtabellen. Welche Datenbank zu welchem Mandanten gehört, steht nicht im SQL Server selbst, sondern in der Datei MESOSERVERCONNECT.MESO auf dem WinLine-Server. Ohne diese Landkarte fragst du im Zweifel die falsche Datenbank ab.
Der zweite und größere Stolperstein sind die Tabellennamen. WinLine benennt seine Tabellen nicht sprechend, sondern kodiert. Die Mesonic-Dokumentation nennt zum Beispiel die mandantenunabhängige Tabelle T220CMP. Reale WinLine-Tabellen heißen nach diesem Muster, nicht Kunden, Artikel, RECH_KOPF oder OP. Diese sprechenden Namen, die in vielen Anleitungen kursieren, gibt es im Datenbestand schlicht nicht.
Das heißt: Der Zugang über SQL ist offen, aber die Bedeutung der Felder ist es nicht. Die eigentliche Arbeit beim Anbinden einer WinLine ist nicht die Verbindung, sondern das Entschlüsseln des kodierten Schemas — welche T-Tabelle ist der Artikelstamm, welche Spalte ist die Warengruppe, was bedeutet eine Statuskennung wie „1″ oder „2″.
Die ehrliche Reihenfolge des Vorgehens
Aus der Praxis im norddeutschen Mittelstand hat sich diese Reihenfolge bewährt.
Schritt 1 — Backend und Mandanten klären. Erst feststellen, ob SQL Server, PostgreSQL oder eine alte MDB drunterliegt, und über MESOSERVERCONNECT.MESO beziehungsweise den WINLine ADMIN ermitteln, welche Datenbank welchen Mandanten enthält. Ohne diese beiden Antworten ist jede Abfrage Ratespiel.
Schritt 2 — nur lesen, niemals in die Live-Datenbank schreiben. Direkter Schreibzugriff auf die WinLine-Tabellen zerstört im besten Fall nur die Konsistenz und kostet im schlechtesten den Support. Der saubere Weg ist ein Lesezugriff mit eigenem Read-only-Login, idealerweise auf einer zurückgesicherten Kopie der Datenbank, nicht auf dem Produktivsystem.
Schritt 3 — das Schema entschlüsseln. Die kodierten Tabellen den Fachbegriffen zuordnen, entweder über die WinLine-Tabellendokumentation oder per Reverse Engineering anhand bekannter Werte. Das ist der Teil, der Zeit kostet, und der Teil, den kein „häng dich einfach dran“ abkürzt.
Schritt 4 — den dokumentierten Export nutzen, wenn die Tabellen zu heikel sind. WinLine bringt mit dem Listgenerator und der EXIM-Funktion eigene, vom Hersteller vorgesehene Exportwege mit. Wer nicht auf der Rohtabellen-Ebene arbeiten will, zieht die Daten darüber als Datei und lädt sie in das eigene DWH.
Das hier ist der Kern eines lesenden Zugriffs aus dem SQL Server, wenn das Backend ein Microsoft SQL Server ist. Der entscheidende Punkt steht im Kommentar, nicht in der Syntax:
-- WICHTIG: Tabellen- und Feldnamen sind in WinLine kodiert (Muster T###/T###CMP),
-- nicht sprechend. Vor dieser Abfrage muss die Schema-Zuordnung geklärt sein.
-- Hier nur als Muster: kodierte Tabelle <ArtikelStamm-T-Tabelle> einer Mandanten-DB.
SELECT TOP 100 *
FROM [Mandant_001].[dbo].[<ArtikelStamm-T-Tabelle>];
Liegt PostgreSQL drunter, läuft der Zugriff nicht über den SQL Server, sondern über den PostgreSQL-ODBC-Treiber. Aus dem SQL Server heraus geht das per Linked Server auf diese ODBC-Quelle, oder du ziehst direkt aus PostgreSQL in dein Staging.
Sobald die Daten als Datei vorliegen, ist der Rest Routine. In den SQL Server geht das per BULK INSERT:
BULK INSERT staging.Winline_Artikel
FROM 'D:\winline_export\artikel.csv'
WITH (
FIELDTERMINATOR = ';',
ROWTERMINATOR = '0x0a',
FIRSTROW = 2,
CODEPAGE = '1252' -- alte WinLine-Stände sind nicht Unicode, sondern codepage-basiert
);
Der CODEPAGE-Hinweis ist kein Detail. WinLine hat erst mit Version 11 auf Unicode umgestellt. Ältere Datenstände kommen codepage-basiert, und wer das beim Import übersieht, sucht den Umlaut-Fehler stundenlang an der falschen Stelle.
Wo der Weg an Grenzen stößt
Bei WinLine ist nicht die Verschlüsselung das Problem, sondern die Undurchsichtigkeit. Die Daten sind erreichbar, aber ihre Bedeutung ist es nicht ohne Schema-Wissen. Wer ohne diese Zuordnung loslegt, baut Auswertungen auf Feldern, die er nicht versteht, und produziert plausibel aussehende, aber falsche Zahlen. Das ist gefährlicher als gar kein Zugriff.
Eine Randnotiz zur Aktualität: Die pauschale Aussage „WinLine hat keine Cloud und keine API“ stimmt so nicht mehr. Mesonic bietet inzwischen eine WEBEdition und Web-Komponenten an. Für die klassische Vor-Ort-Installation im Bestand bleibt der direkte Datenbankzugriff aber der praktisch relevante Weg.
Was das für dich heißt, wenn du es nicht selbst baust
Für dich als Geschäftsführer oder Controller heißt das zweierlei. Erstens: Deine WinLine-Daten sind nicht eingesperrt, sie liegen in einer normalen Datenbank. Das ist die gute Nachricht. Zweitens: Der Aufwand steckt nicht im Zugang, sondern im Verstehen der kodierten Struktur. Wer dir verspricht, das sei „in einer Stunde angebunden“, hat den MESOSERVERCONNECT.MESO noch nicht geöffnet.
Der wirtschaftlich spürbare Unterschied liegt am Ende darin, ob eine Auswertung über mehrere Jahre verlässlich ist oder nur verlässlich aussieht. Genau dafür lohnt es sich, das Schema einmal sauber zu entschlüsseln, statt es bei jeder Frage neu zu raten.
Wenn du sowas im Bestand hast
Wenn bei euch eine Mesonic WinLine läuft und ihr verlässliche Auswertungen oder ein DWH darauf aufsetzen wollt, lohnt sich ein klarer Blick auf Backend-Typ, Mandanten-Struktur und Schema, bevor die erste Abfrage geschrieben wird. Wer das einmal sortieren lassen möchte, erreicht mich über ein kostenloses Erstgespräch.
Quellen
- Datenbankverbindungen WinLine (SQL Server, MSDE, PostgreSQL): MESOWIKI – Datenbank Verbindungen
- Corporate WinLine auf SQL/Oracle: mesonic – WinLine auf SQL-Server
- Mandanten-Zuordnung über MESOSERVERCONNECT.MESO und kodierte Systemtabellen: WINLine ADMIN (PDF)
- Unicode-Umstellung ab Version 11: WinLine Update ab Version 11 (PDF)
Über Sönke Schäfer
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung von Branchen- und ERP-Systemen an SQL Server und Microsoft Access. Sein Schwerpunkt liegt darauf, aus gewachsenen Beständen wie Mesonic WinLine verlässliche Auswertungen und Data-Warehouse-Strukturen zu bauen — mit besonderem Blick auf das Entschlüsseln undokumentierter Datenmodelle. Büro in Sierksdorf, Ostholstein.