Don't copy-paste commands from webpages

Hier mal ein spannender Beitrag über das Kopieren von Websites. Ich muss zugeben, dass ich das auch öfters mal mache. Meistens war es nur bei Stack Overflow und damit landet es meistens in einem Texteditor. Aber wenn man sowas gleich in die Kommandozeile kopiert wird es kritisch. Das Gemeine an dieser Art von verstecktem Befehl ist das "\n", was gleich ein Enter für eine neue Zeile macht. Damit wird der Befehl gleich ausgeführt.
Hier kann man das Beispiel ausprobieren. Und hier gibt es noch mehr Information dazu.

Was lernen wir daraus? Nicht alles blind kopieren, sondern zumindest immer noch in ein Textfeld um zu sehen, was wirklich im Text drin ist.

SQL Grundlagen – Teil 3

Nachdem ich nun schon einen ersten Teil sowie auch schon einen zweiten Teil geschrieben habe, wird es mal Zeit einen weiteren Teil zu schreiben.
Nämlich ein paar Eigenheiten, die man aber immer wieder brauchen kann.

NULL Felder:
Beispielsweise die Prüfung von Checkbox (Boolean) Feldern isnull(a.wichtigerhaken,0)=0. Diese können unter Umständen gar nicht gefüllt sein, angehakt sein oder wieder abgehakt worden sein. Deshalb ist es sinnvoll den Zustand "nicht gefüllt" mit dem Zustand "nicht angehakt" gleichzusetzen. Das geschieht ganz einfach mit der Funktion isnull(). Im ersten Parameter wird das zu prüfende Feld eingetragen und im zweiten Parameter der Wert eingetragen, wenn es tatsächlich NULL also leer ist. isnull(a.wichtigerhaken,0) prüft also das Feld a.wichtigerhaken und setzt eine 0, wenn der Wert wirklich NULL ist. Und mit =0 wird geprüft ob das Feld dann 0 ist.
Würde man diese Prüfung mit isnull nicht machen, würde der Wert ein NULL zurückgeben und somit niemals auf =0 reagieren. Aber da NULL meistens mit 0 gleichzusetzen ist, muss man die NULL Felder mit 0 Werten deklarieren um die Prüfung korrekt durchführen zu können.

Datum beschränken:
Eine sehr einfache Lösung um die Antwortmenge auf einen bestimmten Zeitraum zu beschränken ist der Tag. Dazu macht man in der WHERE Klausel beispielsweise sowas hier um das Datum vor 3 Tagen und bis 14 Tage in der Zukunft zu haben. Dafür ist DATEADD() eine sehr gute Funktion:
and wa.termin >= DATEADD(DAY,-3,GETDATE())
and wa.TERMIN < DATEADD(DAY,14,GETDATE())

Das GETDATE() gibt einfach das aktuelle Datum zurück. Mit DATEADD(DAY,-3,GETDATE()) wird einer Tag ermittelt, der 3 Tage in ausgehend vom aktuellen Datum berechnet wird. DAY ist der Parameter, der besagt, dass der Tag geändert werden soll. Die -3 gibt an, dass 3 Tage zurückgerechnet werden soll und Getdate() gibt eben das aktuelle Datum vom System zurück. Dies ist also ein sehr einfacher Vergleichswert um zu sehen ob der wa.termin kleiner oder gleich das Datum 3 Tage in der Vergangenheit ist.
DATEADD(DAY,14,GETDATE()) macht das Gleiche analog wie oben. Nur 14 Tage in die Zukunft.

UNION:
Man kann auch mehrere Abfragen zusammenfassen. Dafür ist UNION das Mittel der Wahl. Beispielsweise, wenn man Daten für ein Chart benötigt, die sich auch immer auf den gleichen Zeitraum beziehen.
declare @limitAB int
set @limitAB = 100
SELECT wa.Termin,
'Belegt' as Art,
count(wa.nummer) as anzahl
From Warenausgang wa
Where wa.status = 9
Group by wa.Termin
UNION
SELECT wa.Termin,
'Frei' as Art,
case when count(wa.nummer) > @limitAB then 0 else @limitAB - count(wa.nummer) end as Anzahl
From Warenausgang wa
Where wa.status = 9
Group by wa.Termin
Order By wa.Termin, Art

Das obige Beispiel macht eine Abfrage und sucht erstmal die Anzahl der Warenausgänge pro Tag im angegebenem Zeitraum. Gleichzeitig wird auch eine Grenze von 100 definiert set @limitAB = 100. In der unteren SELECT Abfrage wird diese diese Grenze verwendet und die Anzahl der Warenausgänge abgezogen.

So habe ich am Ende eine Ergebnistabelle, welche mir 2 Werte liefert. Einmal die Anzahl der Warenausgänge als "Belegt" und noch die Restmenge als "Frei".
Würde ich nun in einem Programm ein Diagramm basteln, könnte ich so beide Werte in Abhängigkeit vom Termin verwenden.
UNION ist also ganz hilfreich um verschiedene Abfragen miteinander zu verbinden. Damit es funktioniert müssen die Abfragen aber Gemeinsamkeiten aufweisen. Über freie Felder wie in diesem Beispiel 'Frei' as Art kann man die Werte hinterher wieder unterscheiden.
Möchte man die Abfragen am Ende noch mit Order By sortieren ist es wichtig, diese Sortierung am Ende zu machen.

Und damit zurück ins Hauptstadtstudio zum Wetter!

SQL Grundlagen – Teil 2

Natürlich kann SQL noch viel mehr als nur die Standard Selects, wie ich schon im ersten Teil gezeigt habe. Doch es gibt auch noch GROUP BY und ORDER BY.
Wie die Namen schon sagen kann man mit GROUP BY Spalten gruppieren und mit ORDER BY dann auch noch gruppieren.
Mal angenommen wir haben folgende Abfrage:
SELECT ap.Artnr, ap.Bezeichnung, sum(isnull(ap.menge,0))
FROM Auftragposition ap
GROUP BY ap.Artnr, ap.Bezeichnung

Dann wird das SQL Server Management Studio anmerken, dass ein GROUP BY fehlen würde, wenn man es weglässt. Der Grund liegt hierbei, dass wir eine Aggregatfunktion verwenden. Nämlich die Funktion sum(WERT). Damit werden bestimmte Felder summiert.
sum(isnull(ap.menge,0)) besteht in diesem Fall sogar aus zwei Funktionen. Einmal die isnull(ap.menge,0) welche prüft ob das Feld ap.menge NULL also damit leer ist und ersetzt die Menge in diesem Fall durch eine 0. Die 0 ist immerhin ein Wert und kann addiert werden. Diese Funktion ist in die sum() eingebunden.
Die Abfrage wird mir also alle Auftragspositionsmengen gruppiert nach der Artikelnummer und der Bezeichnung ausgeben. Da die Artikelnummer und die Bezeichnung in den allermeisten Fällen immer gleich ist, wird also pro Artikelnummer eine Zeile mit der summierten Menge ausgegeben werden.

Nun kann es aber natürlich auch sein, dass die Ausgabe doch etwas unsortiert herauskommt. Beispielsweise die Artikel 42, danach die 92 und dann die 23. Diese Ausgabe lässt sich natürlich auch ordnen. Dafür setzen wir einfach noch den ORDER BY Befehl drunter und die Abfrage sieht wie folgt aus:
SELECT ap.Artnr, ap.Bezeichnung, sum(isnull(ap.menge,0))
FROM Auftragposition ap
GROUP BY ap.Artnr, ap.Bezeichnung
ORDER BY ap.Artnr

Somit haben wir nun eine eine Ausgabe mit dem summierten Mengen pro Artikelnummer und werden die Ausgabe nach der Position geordnet vorfinden. Mit den Wörtern desc bzw. asc hinter dem Feld in ORDER BY kann man noch bestimmen ob absteigend oder aufsteigend sortiert werden soll.

Kommentar zu Log4j: Es funktioniert wie spezifiziert

Dieser Heise Kommentar zu Log4j ist einfach genial geschrieben. Er bestätigt allerdings auch meine ganze Vorbehalte zu Java. Das Teil hat mich jahrelang als Admin genervt. Ständig Updates der Runtime und damit es läuft muss man immer diese Runtime dabei haben. Der einzige Vorteil war aber tatsächlich, diese Runtime ist für alle gängigen Betriebssysteme verfügbar. Aber so richtig warm bin ich mit Java trotzdem nie geworden.
Dafür ist .NET mit C# sicherlich auch nicht besser. Es lief zumindest bis .NET Core ausschließlich auf Windows. Dafür aber recht zuverlässig und recht angenehm. Und wenn ich mir so den Heise Kommentar durchlese, war es definitiv keine schlechte Idee auf C# zu setzen. Das war und ist um einiges durchsichtiger welcher Code verwendet wird und welcher nicht.
Java ist eine Insel und sicherlich auch eine schöne. Aber als Programmiersprache könnte man das gerne mal ablösen. Rust soll auch sehr schön sein hab ich gehört. :D