Kategorie: SQL

Falls SQLServer ReportingServices (SSRS) mal Leerzeichen verschluckt

Heute ist uns im Projekt aufgefallen, dass SSRS-Tabellenfelder und Textboxen gerne mal Leerzeichen verschlucken. Ärgerlich ist das bei fest formatierten Textbausteinen, wie sie bei Labeltexten häufiger auftreten. Das Problem liegt daran, dass Tabelleninhalte im Report als HTML gerendert werden. Darunter leiden Zeilenumbrüche zwar nicht, aber Spaces am Zeilenanfang oder Folgen von mehreren Spaces werden dabei einfach verschluckt.

Die Lösung ist es wie bei HTML üblich Non-Breaking-Spaces in den Report zu streuen. Diese kann man mit Tastencode ALT-0160 in Windows erzeugen.

Natürlich sind diese wieder alles andere als schön in der Datenbank mit den Labeltexten und unpraktisch beim Einpflegen der Texte.

Besser ist es also die Spaces im Report zu wandeln. Dies kann in der Expression der entsprechenden Control passieren mittels

=REPLACE(Feld.Value," ", " ")

Das zweite Space in der Expression wird dabei natürlich als ALT-0160 via Ziffernblock eingegeben.

MS SQL Server Datetime mal ganz zeitlos

Nach mehreren anderen Varianten habe ich heute endlich die vermutlich performanteste Routine zum Entfernen des Uhrzeit-Anteils aus einem MS SQL Server Datetime Ausdruck gefunden:

    select DATEADD(dd,0,datediff(dd,0,GETDATE()))

Der Trick dabei ist, dass SQL Server die Zahl 0 als ein fixes Bezugsdatum interpretiert. Das Beispielstatement

    select DATEADD(dd,0,0)

zeigt uns das interne Tag Null Referenzdatum 1. Januar 1900.

Die Datediff-Differenz zwischen diesem und dem aktuellen Datum sagt uns wieviele Tage seit dem 1. Januar 1990 vergangen sind. Addiert auf das Bezugsdatum 0 ergibt sich somit wieder das heutige Datum — nur halt ohne Zeit.

Da nur Integer-Operationen genutzt werden statt komplexerer Umwandlungen ist diese Routine viel schneller als String-Format-Umwandlungen wie beispielsweise

    select convert(datetime,convert(varchar(8),GETDATE(),112))

Es bietet sich an unsere Rechenroutine als Funktion anzulegen:

    CREATE function [dbo].[getDateWithoutTime] (@mydate datetime)
    returns datetime
    as
    begin
        return DATEADD(dd,0,datediff(dd,0,@mydate))
    end

MS SQL Server kennenlernen – Tag für Tag

Als Ergänzung zu meinem Eintrag von gestern, mag ich hier noch einmal kurz auf die SQL Server Central Community eingehen. Das ist nämlich der perfekte Ort, um MS SQL Server jeden Tag ein klein wenig besser kennenzulernen.

Neben Artikeln und einem breiten Angebot an Foren haben es mir dort besonders die Fragen des Tages(QOTDs – Question of the Day) angetan, die einen regelmässig auf die Seite zurückziehen. Da es dabei auch Punkte gibt, kann man sich über die Zeit leicht mit anderen DBAs und Entwicklern messen. Doch gerade falsche Antworten sind lehrreich: Die Seite weist in diesem Fall auf die entsprechenden Einträge im Microsoft Developer Network (MSDN) hin.

Auf diese Art geht lernen schnell und macht auch noch Spaß. Einziger Nachteil: man muss seine Email registrieren.

Der zugehörige Link: Welcome to SQL Server Central.

MS SQL Server: Einfach zu einfach?

In meinem Entwickler-Alltag spielt der Microsoft SQL Server oft eine sehr wichtige Rolle und das schon seit der katastrophal fehlerträchtigen Version 6.0. Zwar habe ich auch mit anderen Datenbanken wie beispielsweise DB2, Oracle  oder MySQL zu tun, aber der MS SQL Server hat spätestens seit der stabilen 2000er-Version eine Sonderstellung und ist ein Werkzeug, dem ich einfach überall begegne.

Das hat meiner Meinung nach zwei Gründe:

  1. MS SQL Server ist kinderleicht ans Rennen zu kriegen
  2. er wird mehr und mehr zum Komplett-Paket für alle Business Intelligence Belange, und ist (zumindest wenn man einen Großteil der gelieferten Funktionalität auch wirklich einsetzt) einfach kostenmäßig extrem attraktiv.

Der erste Punkt, die problemlose Einrichtung, ist jedoch nicht ganz ungefährlich: Die Einstiegsanforderungen an einen Datenbank-Administrator (kurz: DBA) sind sehr gering, ich kenne sogar Firmen, die auf die dedizierte Rolle DBA weitestgehend verzichten. Stösst man aber irgendwann an die Grenze, an der die Standardkonfiguration ausgereizt ist, wird es ohne DBA schnell kritisch.

Es ist also Vorsicht geboten. Ich möchte darum in diesem Artikel ein paar der Fallstricke aus meinem Projektalltag knapp umreissen.

Es fängt oft mit Trivialitäten an. Die erste Klippe ist der vorhandene Arbeitsspeicher. Solange dieser groß genug ausfällt, ist es möglich, auch mit größeren Tabellen halbwegs performant auszukommen, und das selbst wenn kein einziger Index definiert wurde.

Geht die Performance dann bei steigendem Datenvolumen irgendwann in den Keller, ist das eine Klippe, die man meist mit Programmierern noch lösen kann. Indizes kriegen Entwickler selbstverständlich noch gut in den Griff. Die wenigsten Entwickler kennen jedoch die breite Werkzeugpalette innerhalb MS SQL Servers, die sich diesem Problem analytisch und zum Teil sogar automatisch annimmt.

Sind die Index-Probleme einmal gelöst, kommt bald eine neuer Eisberg auf uns zu. Auf 32Bit-Systemen ist diese Grenze dann erreicht, wenn die erste Tabelle mehr als 2GB Daten umfasst. Ab diesem Punkt spätestens muckt SQL Server auf: Wir haben den Adress-Raum eines 32-Bit-Systems verlassen, einfachste Operationen auf der Tabelle werden langwierig und spannend wie eine Herz-OP, und nichts ist mehr eitel Sonnenschein. Ich sage nicht, dass diese Klippen nicht zu umschiffen sind, aber ab diesem Punkt werden echte DBA-Kenntnisse unabdingbar. Programmierer kriegen diese Problematik in der Regel nicht mehr in den Griff. Es ist einfach kein Software-Problem mehr; ein Index als Zugriffspfad hat noch etwas Entwickler-Nahes, aber die schnöde Probleme Arbeitsspeicher und Plattenplatz haben meiner Meinung nach nichts in Programmierer-Hand zu suchen.

Fazit: Microsoft SQL Server ist kinderleicht einzuführen, das stimmt. Aber man sollte von Anfang an eine DBA Rolle einführen, auch wenn sie zunächst unnötig erscheint.

Ein guter DBA kennzeichnet sich meiner Meinung nach dadurch, dass man seine Arbeit nicht bemerkt. Fehlt er aber, wird das im Falle von MS SQL Server mit gefährlicher Verzögerung offensichtlich. Oft sind eingeführte Systeme dann schon unternehmenskritisch geworden… es ist also Vorsicht geboten!

Es gibt viele Schrauben im Hintergrund von MS SQL Server, aber wenn man sich regelmässig und gewissenhaft mit ihnen beschäftigt, erhält man auch ein auf Dauer stabiles und performantes System.

Links zum Artikel: