Frank Kalis - Latest Comments

Uwe Ricken [Besucher] in Antwort auf: It's all in the manual, stupid - Trigger

Uwe Ricken [Besucher] — Thu, 16 May 2013 09:54:10 +0000

Lieber Frank,

man rennt häufig einem "Irrglauben" hinterher und muss sich dann verwundert die Augen reiben, wenn man erkennt, dass die bisherige Sichtweise vollkommen falsch ist.

So ist es mir auch erst vor Kurzem ergangen - warum also auch nicht mal ein Anderer :)

Danke für die sehr gute und plastische Erläuterung - ich wäre auch drauf reingefallen!

Torsten Schuessler [Mitglied] in Antwort auf: Entwickler vs. DBA

Torsten Schuessler [Mitglied] — Mon, 13 May 2013 21:31:54 +0000

Ich kann mich noch nicht entscheiden, was ich besser finde :-):

Who are you, the DBA? I thought you quit. Or maybe that was the guy before. It's a pity what happened to him…after he complained about our last application.

oder:

That's when I noticed the code-droppers standing there, hulking, menacing developers, wearing Star Wars t-shirts and each with a paw full of pizza. I tried to ignore them as the Dev Lead started to speak.

Vielen Dank,

tosc

Frank Kalis [Mitglied] in Antwort auf: IIF in T-SQL

Frank Kalis [Mitglied] — Tue, 30 Apr 2013 09:38:49 +0000

Korrekt und Danke für den Link!
Dieser Beitrag ist mittlerweile fast 10 Jahre alt. Ich sollte vielleicht in einem separaten Beitrag darauf aufmerksam machen. :-)

Wolf [Besucher] in Antwort auf: IIF in T-SQL

Wolf [Besucher] — Tue, 30 Apr 2013 08:56:28 +0000

Es gibt ab SQL-Server 2012 den IIF in Transact SQL:

http://msdn.microsoft.com/de-de/library/hh213574.aspx

Und die funktioniert sehr gut. :-)

Frank Kalis [Mitglied] in Antwort auf: Dynamisches SQL : Fluch und Segen

Frank Kalis [Mitglied] — Sat, 29 Dec 2012 22:26:02 +0000

Der Artikel ist eh etwas betagt. ;-)

Ich habe ihn jetzt zwar durch die Rechtschreibprüfung laufen lassen, würde aber empfehlen, Erlands aktualisierten Originalartikel zu lesen.

Hanz [Besucher] in Antwort auf: Dynamisches SQL : Fluch und Segen

Hanz [Besucher] — Fri, 21 Dec 2012 09:49:20 +0000

Nicht ausführlich genug und jede Menge Rechtschreib- und Grammatikfehler.
Bitte überarbeiten, vielen dank :)

MfG Hanz

Armin [Besucher] in Antwort auf: Spaltenwerte als kommaseparierte Liste zurückgeben Teil 2

Armin [Besucher] — Mon, 24 Sep 2012 11:18:34 +0000

So! Aus dem Urlaub zurück und fit für neue Herausforderungen.
Deswegen die späte Meldung. Sorry!
Dein Vorschlag hört sich interressant an. Aber erzeuge ich dann nicht redundante Daten? Ich habe im Moment auch noch so gar keine Vorstellung wie ich das Umsetzen soll und wie genau Du Dir das mit den Konfigurationstabellen vorgestellt hast.
Ich kann ja mal einen groben Abriss über den Aufbau meiner DB geben obgleich das wohl das Off-Topic geht.
Ichabe also eine Tabelle mit Kontakten, eine mit den Abteilungen für die sie tätig sein können, eine Hilfstabelle die Kontakte und Abteilungen m:n verbindet, eine mit den Eskalationsstufen, eine weitere HT die die Eskalationsstufen mit der HT KontakteAbteilungen m:n verbindet und natürlich die Tabelle in der alle Themen aufgelistet sind mit Ihrer jeweiligen Eskalationsstufe als Markierung. Dachte eigentlich das wäre schon ziemlich gut aber besser geht ja immer. vielleicht kann man das ja in einem anderen Themenbereich weiterdiskutieren wenn es hier nicht der richtige Platz ist. gerne auch per Mail..

Frank Kalis [Mitglied] in Antwort auf: Spaltenwerte als kommaseparierte Liste zurückgeben Teil 2

Frank Kalis [Mitglied] — Fri, 07 Sep 2012 05:16:41 +0000

Ja, dann habe ich dich tatsächlich falsch verstanden. Bei solch einer Aufgabenstellung würde ich sowieso dann darüber nachdenken, die diversen Eskalationsstufen in Tabellen abzubilden, um nachzuvollziehen, wann welches Thema welche Stufe erreicht hat und was aufgrund dessen veranlasst wurde und wer wie benachrichtigt werden soll.
Ausserdem würde ich mir Konfigurationstabellen anlegen, wo definiert wird, für welches Thema in welcher Stufe welche Personen eine Mail als Empfänger oder CC: erhalten sollen und dies auch in der Datenbank klar separieren, vielleicht sogar in separaten Tabellen ablegen. Damit reduziert sich der Aufwand dann später auf das Verketten der einzelnen Empfänger in Abhängigkeit von der Eskalationsstufe und du musst nicht erst ermitteln, ob jemand schon vorher benachrichtigt wurde und jetzt auf cc: erscheinen soll.
Ein netter Nebeneffekt ist ausserdem, dass alles datengesteuert abläuft und die Pflege dafür dem Anwender übertragen wird. :-)