Eventuell reite ich jetzt auf etwas rum, was vielleicht nur für mich ein Issue ist. Vielleicht ist es aber auch bereits schon in einer der neueren Reporting Services nach SQL Server 2008 R2 gefixt. Egal, dieser Eintrag ist eh mehr für mich als Referenz gedacht als alles andere. Wenn er jedoch darüber hinaus anderen Zeit und Nerven ersparen kann, umso besser...
Einer meiner Team-Kollegen hat mich gerade auf einen lesenswerten Artikel aufmerksam gemacht.
Neulich hatte ich wieder einmal dieses unbezahlbare Gefühl, dass einfach alles Sinn macht, sobald man es nur oft genug genau liest und (mehr oder weniger zufällig) den Sinn der aneinandergereihten Buchstaben erfasst...
Gerade wenn man denkt, man versteht was so um einen herum vor sich geht und hat eine gewisse Einsicht in SQL Server, kommt es anders, als man denkt und endet in dem, was die Engländer so nett "Facepalm" nennen.
Im ersten Teil dieser kleinen Serie zu agiler Datenbankentwicklung habe ich mich mit der Vorgeschichte befasst, die zu unserer Entscheidung geführt hat, agile Methoden in die Entwicklung einfliessen zu lassen. Dieser Teil endete mit dem Hinweis auf unsere erste Sprint Planung. Der vorliegende Teil nun setzt an diesem Punkt an und beschreibt unser Vorgehensmodell.
Agile Datenbankentwicklung? Kenne ich nicht? Brauche ich das? Was ist das überhaupt? So oder ähnlich habe ich bis vor kurzem auch gedacht, bis wir es dann einfach mal ausprobiert haben.
Wir haben also jetzt vor kurzem unseren ersten Sprint erfolgreich beendet und mein Plan ist, diese Erfahrung und die noch kommenden in einer Art "Mini-Serie" weiterzugeben und vielleicht sogar die eine oder andere Reaktion darauf aus der Leserschaft zu provozieren. Es würde mich freuen, zu hören, wie andere Datenbank-Entwicklung praktizieren. Wo es Gemeinsamkeiten gibt und wo es Unterschiede gibt.
In diesem ersten Teil widme ich mich zunächst einmal den Hintergründen, die zu unserer Entscheidung geführt haben, agile Prozesse in die Datenbankentwicklung einfliessen zu lassen.
Manchmal sieht man den Wald vor lauter Bäumen nicht, wenn man etwas "zwischen Tür und Angel" codiert. Daher dieser kleine Beitrag. Vielleicht hilft er dem einen oder anderen ja, die Zeit für die Fehlersuche zu sparen.
Manchmal kann es nützlich sein, den Wert oder den Ausdruck einer DEFAULT Einschränkung abzufragen.