Inhaltsverzeichnis
  1. SQL Server Management Studio 21/22 noch nicht einsetzen 2 - 4
  2. IBM‑Db2‑Sicherheitslücken 5 - 7
  3. SQL Server 2025 Express: Jetzt 50 GB 8 - 9
  4. ODBC: Fehler im Windows-Treiber 10
  5. SQL-Server 2012 Supportende Mitte 2022 11 - 12
  6. ODBC als Ergänzung zu bi1 13 - 14
  7. Microsoft #SQL-Server 2008 und 2008 R2 Support-Ende 15
  8. Welcher SQL-Server kommt wo am meisten zum Einsatz? 16
  9. ODBC-Wissen 17

SQL Server Management Studio 21/22 noch nicht einsetzen

Microsoft entwickelt das SQL Server Management Studio (SSMS) stetig weiter. Mit den Versionen 21 und 22 wurden einige Modernisierungen eingeführt, die auf den ersten Blick nach einem sinnvollen Fortschritt aussehen. In der Praxis zeigt sich jedoch: SSMS 21/22 ist derzeit für viele administrative Aufgaben noch nicht zuverlässig genug und sollte in produktiven Umgebungen mit Vorsicht betrachtet werden.

Besonders kritisch ist dabei ein Bereich, der in vielen Unternehmen zum täglichen Standard gehört: der SQL Server Agent.

Das Hauptproblem: Fehler beim Bearbeiten von SQL Server Agent Aufgaben

Ein zentrales Problem in SSMS 21/22 betrifft das Bearbeiten von SQL Server Agent Jobs. Gerade beim Öffnen, Bearbeiten oder Speichern von Aufgaben und deren Steps treten immer wieder Probleme auf. Dazu gehören unter anderem Fehlermeldungen beim Speichern, unvollständig geladene Eigenschaften oder fehlerhaft dargestellte Konfigurationen.

Das klingt zunächst nach einem typischen „kleinen UI-Bug“, kann aber schnell ernst werden. Denn SQL Server Agent Jobs sind in vielen Umgebungen das Rückgrat der Automatisierung. Sie steuern Backups, Wartungspläne, Datenimporte, Reporting-Prozesse oder Sicherheitsaufgaben. Wenn ein Tool hier nicht stabil arbeitet, steigt die Gefahr, dass Änderungen nicht korrekt übernommen werden oder Jobs unbeabsichtigt verändert werden.

Warum das im Alltag problematisch ist

SSMS ist nicht nur ein SQL-Editor, sondern das wichtigste Verwaltungswerkzeug für Datenbankadministratoren und IT-Betrieb. In produktiven Umgebungen müssen Änderungen schnell, sauber und nachvollziehbar durchführbar sein. Wenn grundlegende Funktionen wie die Job-Verwaltung nicht fehlerfrei funktionieren, führt das zu unnötigem Mehraufwand, längeren Wartungsfenstern und im schlimmsten Fall zu Ausfällen oder fehlerhaften Abläufen.

Gerade in Zeiten, in denen Datenbanken häufig ein kritischer Bestandteil der gesamten Infrastruktur sind, ist es schlicht keine gute Idee, mit einem instabilen Management-Tool zu arbeiten.

Empfehlung: SSMS 20.x bleibt aktuell die beste Wahl

Wer heute eine stabile und bewährte Umgebung benötigt, sollte weiterhin auf SSMS 20.x setzen. Diese Version bietet die nötige Zuverlässigkeit im täglichen Betrieb, insbesondere bei der Verwaltung von SQL Server Agent Aufgaben. Viele Administratoren nutzen SSMS 20.x weiterhin bewusst, weil es in der Praxis stabil läuft und keine bösen Überraschungen verursacht.

Kurz gesagt: Wer produktiv arbeiten will, fährt mit SSMS 20.x aktuell deutlich besser.

Englisch oder Deutsch? Beides möglich

Ein zusätzlicher Tipp: Die englische Version von SSMS wirkt in vielen Fällen etwas schlanker und ist oft angenehmer in der täglichen Nutzung, insbesondere wenn man Fehlermeldungen oder Workarounds recherchieren muss. Die meisten Microsoft-Dokumentationen und Community-Beiträge beziehen sich auf englische Menüs und Begriffe, wodurch die Fehlersuche deutlich schneller geht.

Die deutsche Version ist aber ebenfalls nutzbar und absolut in Ordnung, vor allem in Teams, die konsequent deutschsprachig arbeiten.

Fazit: SSMS 21/22 derzeit lieber nur zum Testen

SSMS 21 und 22 werden langfristig sicher die Zukunft sein. Aktuell gibt es aber noch zu viele Probleme in wichtigen Verwaltungsfunktionen, insbesondere rund um den SQL Server Agent. Wer auf Stabilität angewiesen ist, sollte deshalb vorerst auf SSMS 20.x setzen und SSMS 21/22 höchstens in Testumgebungen evaluieren.

Für produktive Systeme gilt damit momentan eine klare Empfehlung: SSMS 20.x verwenden und SSMS 21/22 erst dann einführen, wenn die bekannten Schwächen vollständig behoben sind.


IBM‑Db2‑Sicherheitslücken

IBM hat mehrere kritische #Sicherheitslücken im Datenbanksystem IBM Db2 veröffentlicht, die unter bestimmten Umständen lokale Angreifer in die Lage versetzen können, ihre Rechte auszuweiten – im schlimmsten Fall bis hin zu Root‑Rechten. Laut heise sind derzeit über 17 Schwachstellen bekannt, darunter zwei mit hoher Kritikalität, die es Angreifern mit Dateisystemzugriff ermöglichen, privilegierte Operationen auszuführen oder Root‑Zugriff zu erlangen. [heise.de]

Was genau ist betroffen?

Die Schwachstellen betreffen verschiedene Db2‑Versionen, inklusive älterer Releases, die nicht mehr im Support stehen und somit keine Sicherheitsupdates mehr erhalten. Für unterstützte Versionen wie Db2 11.5.9 stehen spezielle Patches (z. B. Special Build #66394) zur Verfügung. Diese beheben insbesondere Privilege‑Escalation‑Lücken sowie diverse Denial-of-Service‑Probleme, die durch manipulierte SQL‑Abfragen ausgelöst werden können.

Bin ich betroffen, wenn Db2 nur im internen LAN läuft?

Viele Unternehmen setzen Db2 ohne externe Erreichbarkeit und ausschließlich intern ein – zum Beispiel als Datenbank für d.3 / d.velop documents Version 8. Die gute Nachricht: Wenn der Db2‑Server nicht aus dem Internet erreichbar ist, sinkt das Risiko deutlich.

Allerdings gilt: Die kritischsten Lücken erfordern lokalen Zugriff auf den Server. Das bedeutet, dass ein Angreifer bereits im internen Netz oder auf dem System aktiv sein müsste, um die Schwachstellen auszunutzen. Das schützt zwar vor externen Angriffen, aber nicht vor:

  • infizierten Arbeitsplätzen im LAN.
  • kompromittierten Dienstkonten.
  • internen Angreifern.
  • Malware, die sich lateral im Netzwerk bewegt.

Kurz gesagt: Nicht aus dem Internet erreichbar bedeutet nicht automatisch sicher.

Was bedeutet das für d.3‑Systeme mit IBM Db2?

Ein wichtiger Punkt: d.velop hat angekündigt, die Unterstützung für IBM Db2 ab 2026 vollständig einzustellen. Bereits heute steht Db2 für Neuinstallationen nicht mehr zur Verfügung, und Bestandskunden erhalten nur noch bis Ende 2026 Support. Eine Migration auf Microsoft SQL‑Server wird ausdrücklich empfohlen. [Wichtige N….dok - GWS]

Damit ergibt sich ein doppelter Handlungsdruck:

  1. Aktuelle Sicherheitslücken beheben
  2. Frühzeitig die Migration auf SQL‑Server planen, da Db2 perspektivisch nicht mehr unterstützt wird

Wie hoch ist das Risiko für meine bestehende d.3‑Installation?

Bewertung für typische d.3‑Umgebungen im LAN:

Du bist wahrscheinlich betroffen, wenn:

  • Du eine ungepatchte oder ältere Db2‑Version einsetzt.
  • Dein d.3‑System weiterhin auf Db2 basiert (Version 8 ist häufig betroffen).
  • Dienstkonten oder Anwendungen mit zu hohen Rechten laufen.
  • es potenzielle interne Angriffswege gibt (z. B. über RDP, SMB, Schwachstellen in Drittsoftware).

Du bist weniger betroffen, wenn:

  • Deine Db2‑Version gepatcht und im Support ist.
  • Der Server gehärtet ist und nach Prinzip „Least Privilege“ betrieben wird.
  • Das System vollständig isoliert ist.
  • Du bereits auf Microsoft SQL‑Server migriert hast.

Klare Empfehlung

Kurzfristig

  • Prüfen, welche Db2‑Version eingesetzt wird.
  • Verfügbare Sicherheitsupdates umgehend installieren.
  • Dienst‑ und Systemkonten prüfen und bereinigen.
  • Serverhärtung durchführen (Firewall, AV, lokale Richtlinien).

Mittelfristig

  • Migration von Db2 auf SQL‑Server planen, da der Hersteller‑Support endet
  • Prüfen, welche d.3‑Komponenten bereits SQL‑Server voraussetzen

Langfristig

  • Moderne Web‑Technologien (z. B. d.3 One) nutzen.
  • Abhängigkeit von abgekündigten Technologien vermeiden.
  • Sicherheitsrisiken reduzieren, die durch veraltete Datenbanksysteme entstehen.

Fazit

Auch wenn dein d.3‑System auf Basis von IBM Db2 nur intern im LAN betrieben wird, kann eine lokale Angriffsfläche bestehen bleiben – besonders, wenn ältere oder ungepatchte Versionen im Einsatz sind. Die aktuelle Entwicklung sowie das bevorstehende Supportende von Db2 bei d.velop machen klar: Eine Migration auf SQL‑Server ist nicht nur sicherer, sondern perspektivisch zwingend notwendig.


SQL Server 2025 Express: Jetzt 50 GB

Mit dem Release von Microsoft SQL Server 2025 (Version 17.x) erhält die kostenlose Express Edition eines der größten Upgrades seit Jahren:
Die maximale Datenbankgröße steigt von 10 GB auf 50 GB. Eine Verfünffachung – und gerade für kleinere Installationen, Offline‑Kassen, Notfall‑Arbeitsplätze oder interne Tools ein echter Vorteil.

Warum das wichtig ist – besonders bei Notfall-Arbeitsplätzen

Viele Notfall‑ oder Offline‑Arbeitsplätze setzen bewusst auf SQL Server Express, weil er (SQL-) lizenzfrei, kompakt und robust ist. Das alte 10‑GB‑Limit zwang jedoch häufig zum Kauf von Lizenzen.

Achtung! Statt Notfall-Arbeitsplätzen, die einen hohen Pflegeaufwand im Normalbetrieb mit sich ziehen, ist eine LTE-Backup-Leitung die bessere Alternative. Zumal es in unseren SaaS-Angeboten keine Notfall-Arbeitsplätze gibt. Eine zukunftsfähige Alternative für die Kassen ist die "Korona-Kasse", die einen Notbetrieb erlaubt und über moderne Schnittstellen an gevis angebunden ist.

Mit 50 GB ist nun ausreichend Platz für gewachsene Datenbestände – ohne sofort auf die Standard‑Edition wechseln zu müssen.

Vergleich der wichtigsten Editionen (SQL Server 2025)

FeatureExpress 2019Express 2022Express 2025Standard 2025Enterprise 2025
Max. DB‑Größe10 GB10 GB50 GBOS‑LimitOS‑Limit
CPU‑Limit1 Socket / 4 Cores1 Socket / 4 Cores1 Socket / 4 Coresbis 32 Coresunbegrenzt
RAM (Buffer Pool)~1,4 GB~1,4 GB~1,4 GB256 GBOS‑Limit
Full‑Text SearchNeinNeinJaJaJa
Reporting ServicesNur Adv.Nur Adv.JaJaJa
Machine LearningNeinNeinBasic MLerweitertvoll
SQL AgentNeinNeinNeinJaJa
High AvailabilityNeinNeinNeineingeschränktvoll

Quelle zu neuen Express-Funktionen und Limit-Erhöhung:
– Microsoft Learn: Kapazitätsänderungen für Express (50 GB)
– DatabaseMart: Vergleich Express 2019/2022/2025 (50‑GB‑Limit) [learn.microsoft.com] [databasemart.com]

Fazit

Mit SQL Server 2025 Express wächst die kleinste Edition über sich hinaus. Die neue 50‑GB‑Grenze, integrierte Advanced‑Features und eine modernisierte Engine machen Express zur idealen Lösung für viele KMU‑Szenarien – insbesondere für Notfall-Arbeitsplätze, Testsysteme und kleinere Fachanwendungen.


ODBC: Fehler im Windows-Treiber

Viele von Ihnen nutzen Microsoft Query oder Microsoft Access, um eigene Auswertungen über die ODBC-Schnittstelle zu ziehen. Wer nicht den "ODBC Treiber 17.x" verwendet, sondern den Treiber, der bei Windows 10 bzw. Server 2016-22 mitgeliefert wird, hat mit dem November kumulativen Update das Problem, dass keine ODBC-Verbindungen mehr aufgebaut werden können.

Ob Sie den Betriebssystemtreiber verwenden, können Sie bei aufgetretener Fehlermeldung in einer administrativen Eingabeaufforderung mit dem Befehl: tasklist /m sqlsrv32.dll feststellen.

Wenn ja, gibt es derzeit von Microsoft keine Lösung für das Problem. Mit dem #ODBC Treiber 17 ist es mir bisher nicht aufgetreten. Damit könnte ein Workaround (der Treiber ist ohnehin der empfohlene Weg - auch nicht die Version 18 des Treibers, sondern die aktuelle Version 17.10.2.1) die Installation und Einrichtung der Datenquellen mit dem 17er Treiber sein. Dieser verwendet die Bibliothek: mssqlodbc17.dll.

Nutzer des 17er Treibers sollten ebenfalls diesen auf die aktuelle Version von Ende November 2022 bringen, um potentielle #Sicherheitslücken zu schließen.

https://go.microsoft.com/fwlink/?linkid=2217421&clcid=0x407

Microsoft Download-Link deutscher Treiber 17

SQL-Server 2012 Supportende Mitte 2022

Viele von Ihnen setzen in Verbindung mit gevis ERP | BC, gevis ERP | NAV und gevis Classic die sogenannte ISV-Runtime des Microsoft SQL-Servers ein. Mit einer jährlich zu verlängernden "Maintenance" (Wartung) wird Ihnen das Recht gewährt, auf eine neuere Version vom SQL-Server zu aktualisieren. Darüber ist, solange Sie nur unsere Produkte (gevis, s.dok, BI1, NAV Lohn) auf diesen SQL-Servern einsetzen) die Lizenz deutlich günstiger als ein vollwertiger SQL-Server Standard.

Ab Mitte Juli 2022 gibt es keine Sicherheits-Updates mehr für #SQL Server 2012. #Sicherheitslücken sind damit vorprogrammiert.

[time_until date="12.07.2022"]

Die Notwendigkeit, ein SQL-Versions-Upgrade auszuführen, tritt immer dann ein, wenn das Supportende des installierten Produkts abläuft oder eine neue gevis Version/Architektur eingesetzt wird (wie im Rahmen einer gevis ERP | BC Migration). Das Upgrade ist immer genau auf die Version mit dem kumulative Upgrade möglich, die von der verwendeten NAV-Version unterstützt wird.

So kann man mit Dynamics NAV 2017 maximal auf SQL-Server 2017 mit einem der ersten kumulativen Updates (CU) aktualisieren, nicht auf SQL-Server 2019. Zusätzlich gibt es eine Abhängigkeit zum verwendeten Server-Windows-Betriebssystem. Alte SQL-Server Versionen können nicht auf Windows Servern der Version 2019 oder 2022 installiert werden.

Handlungsbedarf

  • Stellen Sie Ihre gevis Version fest und die darunterliegende Version von Microsoft Dynamics NAV bzw. Microsoft Dynamics 365 Business Central.
  • Ermitteln Sie im SQL-Server Management Studio die Version Ihres SQL-Servers (z.B. 12.0.2034.21234)
  • Dokumentieren Sie die Windows-Version Ihres SQL-Servers (und der NSTs/Batchserver)
  • Prüfen Sie, ob Sie die SQL-Server Maintenance immer verlängert haben und aktuell ein Wartungsvertrag vorliegt.

Wenn eine aktive SQL-Server-Maintenance und die Umgebungsbedingungen dies erlauben, können Sie die Durchführung des Upgrades unter Einlieferung der oben genannten Ergebnisse bei uns beauftragen. Wir berechnen dann nur die Dienstleistung-Stunden, die wir per Fernwartung für das Durchführen der Aktualisierung benötigen, zum jeweils gültigen Stundensatz.

Liegt keine aktive Maintenance vor, müssen Sie zusätzlich die SQL-Server Lizenzen leider neu lizensieren (oder im Rahmen einer Cloud-Migration in Microsoft Azure anmieten). Auch hier bieten wir Ihnen die SQL-ISV-Runtime Lizenzen gern an.

Ihr Ansprechpartner für die Angebote ist Andreas Lübke.


ODBC als Ergänzung zu bi1

Wer Auswertungen zu gevis erstellen möchte, hat zunächst einmal die Berichte, die die Warenwirtschaft an Bord hat. Als zweite Stufe kann man die "Open Database Connectivity" - kurz #ODBC nutzen, um direkt mit Excel auf aktuelle Daten der #SQL-Server basierten gevis-Datenbank zuzugreifen.
Ebenfalls bekannt ist lizenzpflichtige die Excel-Erweiterung "Jet Essentials", die schon mehr Möglichkeiten bietet, da sie die #Dynamics Begrifflichkeiten an die Oberfläche führt.

Alle Auswertungen, die die dritte Dimension erfordern, lassen sich nur mit einer professionellen BI-Lösung nutzen. Das Produkt "bi1" unserer Tochtergesellschaft Diacom ist optimal auf gevis ERP | NAV abgestimmt, da es die Funktionalität eines Datawarehouse mit dreidimensionalen Würfeln auf gevis abbildet. Zahlreiche Auswertungen für das Management-Cockpit, Verkaufsauswertungen stehen hier bereits zur Verfügung und lassen sich über die intuitive Oberfläche erweitern.

Nun zurück zu ODBC. Die folgenden Grenzwerte sind aufgrund der Software zu beachten:

  • Microsoft Office Standard: Hier steht ausschließlich "MS-Query" zur Verfügung, ein komfortables Programm, um Auswertungen zu erstellen und mehrere Tebellen miteinander zu verknüpfen. Sein Vorteil liegt im Query-Assistenten, der es erlaubt, SQL-Filter ohne SQL-Kenntnisse in natürlicher Sprache zusammenzuklicken.
    • Limits: gevis darf nicht mehr als 4 Mandanten haben, sonst kann Query die Tabellen nicht einlesen
    • Es dürfen maximal 255 Spalten in Excel übergeben werden
    • Erstellte listen lassen sich nicht gruppieren (hierzu muss man in Excel den Pivot-Assistenten im Nachgang bemühen
    • Excel kann maximal 1 Million Zeilen darstellen
  • Microsoft Office 365 ab Proplus Plan oder Office 2019 Proplus: Mit Access lassen sich beliebig große Listen einlesen und weiterverarbeiten
    • Access hat keinen Pivot-Assistenten, zur Weiterverarbeitung müssen Daten aus Access nach Excel exportiert werden.
    • Der Query (Abfrage) Assistent setzt SQL-Kenntnisse voraus (WHERE name LIKE '%Mei%')

Fazit

Wem die genannten Limits kein Problem sind, dem bietet sich eine optimale Kombination aus gevis Berichten + ODBC mit Excel (Bordmittel) und bi1 (Cubes, dreidimensionale und professionelle Auswertungen).


Microsoft #SQL-Server 2008 und 2008 R2 Support-Ende

Das Ende des "extended Support" ist am 9. Juli 2019. Ab diesem Zeitpunkt werden auch keine Sicherheits-Updates für den SQL-Server mehr ausgeliefert. 
Prüfen Sie bitte (bei Aufruf des SQL-Server Management Studios wird die Information angezeigt), welche Version Ihre SQL-Server haben. Bei den oben genannten Produkten besteht Handlungsbedarf: 

 Aktualisierung auf eine neue Version von Microsoft SQL-Server 

Folgende Fragen sind für die Abschätzung des Aufwandes und der Kosten wichtig: 

  • Auf welcher Windows Server Version ist der SQL-Server installiert (2008 R2)?
  • Haben Sie noch einen gültigen Wartungsvertrag (Maintenance)? :! Setzen Sie einen SQL-Mirror-Server ein (Spiegelung)?
  • Ist Ihr SQL-Server nach Prozessor(en) lizensiert?
  • Haben Sie eine neuere SQL-Lizenz und setzen per Downgrade Recht 2008 R2 ein?
  • Setzen Sie Virtualisierung (vmware oder Hyper-V) mit mehren Hosts ein (Cluster)?

Die Beantwortung dieser Fragen entscheidet darüber, ob Sie bis zum Ablaufdatum zusätzliche Lizenzen erwerben müssen oder nur Dienstleistungsaufwand berücksichtigen müssen. Ihr Ansprechpartner ist Dirk Andreas Lübke. Für Fragen und für ein Angebot nehmen Sie gern Kontakt mit ihm auf.


Welcher SQL-Server kommt wo am meisten zum Einsatz?

#PostgreSQL - (mit dem Elefanten-Symbol) ist eine leistungsfähige quelloffene Datenbank-Serverlösung, die alle drei Monate aktualisiert wird. PSQL kommt häufig in Internet-Projekten zum Einsatz #MySQL (Community Edition) ist der Open-Source Teil der meistverbreitetsten Internet-Webserver-Datenbank, der Oracle gehört. Die Community Edition ist kostenfrei und für alle Plattformen verfügbar #Microsoft SQL Server (kostenpflichtig) ist die Datenbank, die in vielen kaufmännischen Produkten und professioneller Geschäfts-Software zum Einsatz kommt. In den aktuellen Versionen entweder "on premise" also im eigenen Netzwerk , oder in der Cloud (Microsoft Azure) #FAQ Kategorie: SQL-Server (3)

ODBC-Wissen

n rn
Datentypen beim Zugriff auf gevis ERP / SQL und verknüpfen von Tabellen mit unterschiedlichen Datentypen, warum nur Leserechte?rnrnWenn ein Dateityp beim verknüpfen von Tabellen nicht passt, erstellen Sie bitte eine Sicht in der Datenbank. (Die geschieht über das SQL Management Studio. Bei der Sysko-SQL-Schulung haben wir das mit der Sicht AAA_Debitor schon gemacht). In der Sicht kommt für die Spalte, die Sie mit einem anderen Datentyp benötigen, dann der CAST Befehl zum Einsatz. Statt der Tabelle selektieren Sie dann zukünftig diese Sicht.rnrnSchreibzugriff würde bei einer kleinen Unachtsamkeit (z.B. ein Komma statt eines Punktes eingegeben) das ganze gevis schrotten. Daher geben wir dem ODBC-User ausschließlich DB-Datareader Rechte. (Post ID:323)n