SQL Server-Agent Auftragsdetails mit SQL ermitteln

SQL-Ser­ver spei­chert umfas­sen­de Infor­ma­tio­nen zu Auf­trä­gen – wie Lauf­zeit, Erfolg, nächs­te Aus­füh­rung etc. – in der Sys­tem­da­ten­bank msdb. Damit die­se Infor­ma­tio­nen aus­ge­wer­tet und ver­ar­bei­tet wer­den kön­nen, müs­sen sie zunächst extra­hiert wer­den. Die­ser Bei­trag erklärt, wie solch eine Extrak­ti­on abläuft.
wei­ter­le­sen…

Datentypänderung mit Systemtabellen

Wenn sich Daten­ty­pen im Vor­sys­tem, aus wel­chem Daten in Tabel­len einer SQL-Ser­ver-Daten­bank impor­tiert wer­den, ändern, ist oft gro­ßer manu­el­ler Auf­wand not­wen­dig um alle betrof­fe­nen Tabel­len und Spal­ten zu iden­ti­fi­zie­ren und anzu­pas­sen. In die­sem Bei­trag wird eine Lösung mit­hil­fe von Sys­tem­ta­bel­len vor­ge­schla­gen, die es ermög­licht, die Daten­ty­pän­de­rung auto­ma­tisch per Pro­ze­dur vor­zu­neh­men. wei­ter­le­sen…

Dekumulieren von Kennzahlen mit SQL

In den meis­ten OLAP-Model­len, die wir mit unse­rem Delta­Master Mode­ler oder auch direkt im BI-Stu­dio erstel­len, gibt es die Mög­lich­keit, Kenn­zah­len kumu­liert dar­zu­stel­len. Die Kumu­la­ti­on wird meis­tens per MDX im Cube­script ange­legt, zum Bei­spiel über eine Aggre­ga­te-Anwei­sung wie in fol­gen­dem Bei­spiel, in wel­chem die bis­her nicht kumu­lier­ten Kenn­zah­len auf Jah­res­ebe­ne aggre­giert wer­den:

Aggregate(PeriodsToDate([Period].[Period].[Year], [Period].[Period].CurrentMember),[Cumulation].[Cumulation].[Cumulation].&[1])

Alter­na­tiv kön­nen kumu­lier­te Kenn­zah­len auch bereits auf der rela­tio­na­len Daten­bank ermit­telt wer­den wie es im Bei­trag SUM-Whe­re OVER the rain­bow“ schon sehr anschau­lich von Tors­ten Krebs beschrie­ben wur­de.

Mit­un­ter ist es aber erfor­der­lich kumu­liert gelie­fer­te Daten wie­der zu deku­mu­lie­ren. wei­ter­le­sen…

CustomApp Teil2 – Anwendung im Web

In dem Arti­kel Custom­App Teil1 – Anwen­dung im Cli­ent“ (im Fol­gen­den Teil1 genannt) wur­de bereits beschrie­ben, was mit einem benut­zer­de­fi­nier­ten Menü im Cli­ent mög­lich ist, wel­che Vor­aus­set­zun­gen not­wen­dig sind und wie mit den ein­zel­nen Menü­va­ri­an­ten gear­bei­tet wer­den kann. In dem nun fol­gen­den zwei­ten Teil soll erläu­tert wer­den, was mit der Vari­an­te der Custom­App als Web­kom­po­nen­te mög­lich ist und wel­che Unter­schie­de zu der Cli­ent-Vari­an­te bestehen. wei­ter­le­sen…

CustomApp Teil1 – Anwendung im Client

Bereits im Okto­ber 2010 bzw. Janu­ar 2011 beschrieb Enri­co Krel­ler in sei­nen Bei­trä­gen Ein­bin­dung eines benut­zer­de­fi­nier­ten Menüs in den Delta­Master” Teil 1 und Teil 2 die Mög­lich­keit, im Delta­Master ein sepa­ra­tes Menü anzu­zei­gen, über das der Anwen­der die ver­schie­dens­ten Aktio­nen aus­füh­ren kann:

Ein­bin­dung eines benut­zer­de­fi­nier­ten Menüs in den Delta­Master Teil 1
Ein­bin­dung eines benut­zer­de­fi­nier­ten Menüs in den Delta­Master Teil 2

Die­ses benut­zer­de­fi­nier­te Menü heißt nun nicht mehr Data­En­try­Me­nue son­dern Custom­App und ver­fügt über ver­bes­ser­te Funk­tio­na­li­tä­ten und Kom­po­nen­ten, die den Ein­satz sowohl im Delta­Master-Cli­ent als auch in der web­ba­sier­ten Delta­Master-Anwen­dung ermög­li­chen.

Inhalt die­ses Arti­kels soll daher der Ein­satz des Menüs im Delta­Master-Cli­ent sein. Die Beschrei­bung, wie die­ses Menü im Web funk­tio­niert, erfolgt in Teil2 zu einem spä­te­ren Zeit­punkt.

Den gesam­ten Arti­kel kön­nen Sie hier abru­fen. wei­ter­le­sen…

Dynamisches SQL mit Ausgabeparameter

Dyna­mi­sches SQL erlaubt die Defi­ni­ti­on und Aus­füh­rung von SQL-Anwei­sun­gen zur Lauf­zeit. Tei­le der Anwei­sun­gen befin­den sich in Varia­blen, die ihre Wer­te zur Lauf­zeit ändern kön­nen. So kann ein dyna­misch erstell­tes SQL-State­ment bei Ver­än­de­rung der Varia­blen immer wie­der ver­wen­det wer­den ohne neu erstellt wer­den zu müs­sen.

Jeder von uns hat sicher bereits dyna­mi­sches SQL ent­wi­ckelt und ver­wen­det. Sel­te­ner wird dabei ein Aus­ga­be­wert benö­tigt. Aber genau um den soll es in die­sem Arti­kel gehen, da die Pro­gram­mie­rung eines Aus­ga­be­wer­tes inner­halb eines dyna­mi­schen SQL-State­ments bestimm­ten Regeln unter­liegt.

Im Bei­spiel wird eine Pro­ze­dur zum Kopie­ren von Wer­ten der Wert­art 1 zu Wert­art 2 bei defi­nier­tem Zeit­punkt und Kun­den in der Daten­bank Chair erstellt. Es wird dafür dyna­mi­sches SQL ein­ge­setzt, weil sich die zu kopie­ren­den Wer­te in meh­re­ren Tabel­len befin­den. Dabei soll zuvor ermit­telt wer­den, ob es zu die­sem Zeit­punkt und bei die­sem Kun­den bei der Wert­art 1, die kopiert wer­den soll, über­haupt Daten vor­lie­gen. Die­se Anzahl Daten­sät­ze ist also der Aus­ga­be­wert, der für jede Tabel­le ermit­telt wird.
wei­ter­le­sen…

Automatischer Datenimport bei sporadischer Dateibereitstellung (Polling per SSIS)

Daten sind die Grund­la­ge jedes BI-Pro­jekts – ohne Daten ist kei­ne Ana­ly­se mög­lich. Aber woher kom­men die­se Daten? Häu­fig wird eine SQL-Ser­ver-Daten­bank als rela­tio­na­le Daten­quel­le gewählt. Aber meis­tens lie­gen nicht alle Daten in die­ser Daten­bank bereits vor. Dann müs­sen die feh­len­den Daten in die SQL-Ser­ver-Daten­bank impor­tiert wer­den. Die Quel­len für die­se Daten­im­por­te kön­nen sehr viel­fäl­tig sein – von ande­ren Daten­ban­ken bis hin zu Text­da­tei­en. Um sich die Arbeit des Daten­im­ports zu erleich­tern, bie­tet sich die Ver­wen­dung der SQL Ser­ver Inte­gra­ti­on Ser­vices (SSIS) von Micro­soft an. Daten aus ver­schie­dens­ten Quel­len las­sen sich hier pro­blem­los ver­ar­bei­ten. Die Auto­ma­ti­sie­rung über einen Sche­du­ler ist eben­falls leicht zu rea­li­sie­ren.

Was kann man aber tun, wenn man Daten in spo­ra­di­schen Zeit­ab­stän­den impor­tie­ren soll und den Import nicht manu­ell aus­füh­ren möch­te? Weiß man nicht, wann die Datei vor­liegt, benö­tigt man ein SSIS-Paket, das prüft, ob eine Datei in einem vor­ge­ge­be­nen Ver­zeich­nis vor­han­den ist und die Ver­ar­bei­tung auch nur dann star­tet. Nach dem Import muss die Datei gelöscht oder zumin­dest umbe­nannt wer­den, um einen erneu­ten Import der glei­chen Daten am nächs­ten Aus­füh­rungs­ter­min des SSIS-Pake­tes zu ver­hin­dern.

Genau dies soll hier am Bei­spiel eines Imports von Plan­da­ten aus einer CSV-Datei in die Chair-Daten­bank gezeigt wer­den. wei­ter­le­sen…

Stilregeln in SQL- und MDX-Statements sowie SSIS-Paketen

Jeder, der selbst SQL- oder MDX-State­ments schreibt und die ande­rer lesen und ver­ste­hen möch­te, wird fest­stel­len, dass jeder einen etwas ande­ren Schreib­stil ver­wen­det. Da T-SQL eine fle­xi­ble Gestal­tung der State­ments zulässt, kön­nen Schlüs­sel­wör­ter, Objekt­na­men und Kon­stan­ten frei über die Zei­len der State­ments ver­teilt wer­den.

Das gilt sowohl für SQL- und MDX-State­ments im Micro­soft SQL Ser­ver Manage­ment Stu­dio als auch für Berech­nun­gen mit MDX im Micro­soft Visu­al Stu­dio. Dies kann vor allem bei län­ge­ren State­ments schnell unüber­sicht­lich wer­den und damit viel Zeit kos­ten die­se zu ver­ste­hen. Das betrifft auch uns selbst, wenn wir nach län­ge­rer Zeit das State­ment wie­der auf­ru­fen und uns fra­gen, was wir damit eigent­lich bewir­ken woll­ten. Ähn­lich ist es bei SSIS-Pake­ten. Hier sind zwar die ein­zel­nen Ele­men­te vor­ge­ge­ben, aber ihre Anord­nung und ihre kon­kre­te Funk­ti­on sind jeweils frei defi­nier­bar.

Daher kön­nen ein paar grund­sätz­li­che Stil­re­geln für SQL- und MDX-State­ments sowie für SSIS-Pake­te für mehr Über­sicht­lich­keit und Les­bar­keit sor­gen. wei­ter­le­sen…