Ein Malerbetrieb will wissen, welche Baustellen wirklich Gewinn gebracht haben und welche nur Arbeit waren. Die Zahlen stecken in WinWorker, und irgendwer hat gesagt: „Da kommst du nicht richtig ran, das ist keine echte Datenbank, da geht nur Export nach Excel.“ Also klickt jemand jeden Monat dieselben Listen heraus und baut sie in Excel zusammen.
Das ist unnötig. Denn die Annahme stimmt nicht: Unter WinWorker liegt eine vollwertige Datenbank, und zwar eine, die du gut kennst.
Was unter WinWorker wirklich liegt
WinWorker ist eine Handwerkersoftware für das Bau- und Ausbauhandwerk, mit Angebots- und Rechnungserstellung, Aufmaß, Nachkalkulation, Zeiterfassung und über fünfzehn Gewerkeprofilen vom Maler bis zum SHK-Betrieb.
Der entscheidende Punkt, den ältere Einschätzungen falsch darstellen: WinWorker läuft auf dem Microsoft SQL Server. Der Hersteller nennt in den Systemvoraussetzungen ausdrücklich die SQL Server Vollversion sowie die kostenfreie Express-Edition, und ab fünf Arbeitsplätzen wird der Server-Betrieb empfohlen. Die Umstellung von einer Einzelplatz- auf eine Mehrplatzinstallation ist genau der Wechsel auf eine SQL-Server-Datenbank.
Das heißt für die Auswertung: Es gibt kein proprietäres Dateiformat, das man erst knacken müsste. Es ist ein SQL Server, an den sich jedes Standardwerkzeug anschließen lässt, das du ohnehin im Haus hast.
Was das ändert: direkter SQL-Zugriff statt Export-Geklicke
Die ältere Sichtweise „nur CSV-Export, kein direkter Zugriff“ verschenkt das eigentliche Potenzial. Weil WinWorker auf SQL Server liegt, kannst du die Daten direkt lesen, statt sie über Listen zu exportieren.
Aus dem SQL Server heraus arbeitest du ohnehin nativ. Aus Access verknüpfst du die Tabellen per ODBC. Das hier ist der Kern einer ODBC-Verknüpfung aus VBA, der entscheidende Punkt steht im Kommentar:
' WinWorker liegt auf SQL Server. Tabellen lassen sich direkt verknüpfen.
' WICHTIG: eigenes Read-only-Login verwenden, NICHT den Dienstaccount,
' mit dem WinWorker selbst auf die Datenbank zugreift.
DoCmd.TransferDatabase acLink, "ODBC Database", _
"ODBC;DRIVER=ODBC Driver 17 for SQL Server;" & _
"SERVER=SQLEXPRESS_INSTANZ;DATABASE=WinWorker;" & _
"Trusted_Connection=yes;", _
acTable, "<Angebotstabelle>", "tblAngebote"
Tabellen- und Feldnamen sind herstellerspezifisch. Sprechende Namen wie ANGEBOT oder RECHNUNG, die in manchen Anleitungen auftauchen, sind nicht garantiert die echten Namen. Die tatsächliche Struktur ermittelst du aus dem SQL Server selbst oder über die WinWorker-Dokumentation. Deshalb steht oben ein Platzhalter.
Zwei Regeln, bevor die erste Abfrage läuft
Erstens, nur lesen. Auch wenn der Zugang einfach ist, gehört kein Schreibzugriff auf die WinWorker-Datenbank. Ein eigenes Login mit Leserechten, mehr nicht. Schreibender Zugriff kann die Konsistenz zerstören und den Herstellersupport kosten.
Zweitens, auf einer Kopie arbeiten. Für Auswertung und DWH ist der saubere Weg, eine zurückgesicherte Kopie der SQL-Server-Datenbank abzufragen oder einen Read-only-Spiegel, statt das Produktivsystem unter Last zu belasten. Weil es ein SQL Server ist, ist genau das einfaches Standard-Handwerk: Backup einspielen und darauf arbeiten.
Die Schnittstellen, die schon da sind
Ein zweiter Punkt, den ältere Einschätzungen unterschlagen: WinWorker ist nicht schnittstellenlos. Etabliert sind unter anderem eine DATEV-Schnittstelle für die Buchhaltung, GAEB für Ausschreibungen, Datanorm und ÖNorm für Artikel- und Preisdaten der Lieferanten sowie IDS-Connect und UGL für die Großhandelsanbindung.
Für eine Auswertung heißt das: Bevor man über den direkten Datenbankzugriff nachdenkt, lohnt der Blick, ob eine dieser dokumentierten Schnittstellen den Zweck schon erfüllt. Für ein echtes DWH über mehrere Jahre ist der direkte SQL-Zugriff trotzdem meist der sauberere Weg.
Der Weg über Export, wenn kein Zugriff gewünscht ist
Wenn der direkte SQL-Zugriff nicht freigegeben wird, bleibt der Export. In fast jedem WinWorker-Modul lassen sich Listen als CSV oder Excel ausgeben. Beim Import in den SQL Server gilt:
BULK INSERT staging.WinWorker_Auftraege
FROM 'D:\winworker_export\auftraege.csv'
WITH (
FIELDTERMINATOR = ';',
ROWTERMINATOR = '0x0a',
FIRSTROW = 2,
CODEPAGE = '1252' -- ältere Exporte sind codepage-basiert, nicht UTF-8
);
Für wiederkehrende Importe richtest du einen SQL-Server-Agent-Job oder ein kleines SSIS-Paket ein, statt die Datei von Hand zu laden.
Wo der Weg an Grenzen stößt
Bei WinWorker ist weder eine fremde Engine noch Verschlüsselung das Problem. Die einzige Hürde ist das Verständnis des Datenmodells: welche Tabelle die Nachkalkulation hält, wie Angebote, Aufträge und Baustellen zusammenhängen, was die Statuswerte bedeuten. Wer das ohne dieses Wissen zusammenrechnet, bekommt einen Gewinn je Baustelle, der plausibel aussieht, aber die Stunden falsch zuordnet.
Was das für dich heißt, wenn du es nicht selbst baust
Für dich als Handwerksunternehmer ist das eine gute Ausgangslage. Deine WinWorker-Daten liegen in einer normalen SQL-Server-Datenbank, oft sogar in der kostenfreien Express-Edition. Der Aufwand steckt nicht im Zugang, sondern im sauberen Lesen der Struktur und in der Entscheidung zwischen vorhandener Schnittstelle und direktem Zugriff.
Der spürbare Unterschied: Einmal richtig angebunden, liefert das Chef-Dashboard die Zahlen zu Umsatz, offenen Posten und Projektständen jeden Morgen von selbst, statt dass jemand sie monatlich aus WinWorker herausklickt und in Excel zusammensetzt.
Wenn du sowas im Bestand hast
Wenn bei euch WinWorker läuft und ihr verlässliche Auswertungen oder ein Controlling darauf aufsetzen wollt, lohnt sich ein sauberer, lesender Zugriff auf die SQL-Server-Datenbank, am besten auf einer Kopie, mit klarem Verständnis des Datenmodells. Wer das einmal aufsetzen lassen möchte, erreicht mich über ein kostenloses Erstgespräch.
Quellen
- Systemvoraussetzungen mit SQL Server / Express: WinWorker – Hard- und Softwarevoraussetzungen (PDF)
- SQL-Server-Mehrplatzbetrieb und Datensicherung: WinWorker-Betreuung – Alpha Team
- Schnittstellen (DATEV, GAEB, Datanorm, IDS-Connect): WinWorker im Test
Über Sönke Schäfer
Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Anbindung von Branchen- und Handwerkssoftware an SQL Server und Microsoft Access. Sein Schwerpunkt liegt darauf, aus gewachsenen Beständen wie WinWorker verlässliche Auswertungen und Controlling-Strukturen zu bauen — direkt auf der SQL-Server-Datenbank, ohne das laufende System zu gefährden. Büro in Sierksdorf, Ostholstein.