Bei der Erstellung eines SQL Server Reports mit einer Weltkarte kam es bei mir die Tage leider immer wieder zu folgenden Fehlermeldungen:
Erst später ist mir bewusst geworden, das der Report mit meiner eingebetteten Weltkarte eine Größe von ca. 10 MB hat.
Der Fehler an dieser Stelle ist eigentlich bekannt und auch eigentlich kein direkter Fehler, erst recht nicht der der SQL Server Reporting Services. ASP.NET Anwendungen sind prinzipiell so konfiguriert, dass nur Dateien mit einer max. Größe von 4MB (28 MB im IIS 7) auf den Server übertragen werden können. Die Einstellung selber lässt sich durch Anpassungen an der web.config beheben, jedoch wird hiervon im Rahmen von Security Best Practices abgeraten.
Das Problem liegt aber eigentlich an den Shape-Dateien. Möchte ich nämlich folgenden Report darstellen
so beinhalten die Daten auch die folgende Informationen:
Ähnliche detaillierte Daten sind auch in der oberen Region von Canada oder an der Küste von Chile zu finden. Diese Menge an Daten, die wahrscheinlich für die meisten Anwender und einer einfachen Darstellung der Erde viel zu komplex sind, sind primär dafür zuständig, dass die Daten nicht auf den Server geladen werden können.
Eine Möglichkeit den Report kleiner zu bekommen, ist den ShapeFile inkl. der DBF Datei auf einen ReportServer zu laden, jedoch gilt auch hier die oben angesprochene Größenbeschränkung und hilft damit nicht wirklich weiter.
Eine weitere Möglichkeit die Größe des Reports zu verkleinern ist alle nicht benötigten Daten zu entfernen. Hiermit meine ich im ersten Moment Daten aus der zum ShapeFile gehörenden dbase Datei. Hier werden häufig viele Felder mitgeliefert die später nicht im Bericht verwendet und/oder angezeigt werden.
Eine weitere Möglichkeit den Bericht bzw. die Datenmengen zu verkleinern, ist es die ShapeFiles direkt im BIDS oder im Report Builder zu bearbeiten und nicht benötigte Polygone zu löschen.
Zumindest bei meiner Weltkarte sind jedoch beide Methoden nicht ausreichend um die Daten so zu reduzieren, dass der Bericht auf dem Server gespeichert werden kann. Und dabei würden meine “neuen” Karten mit Sicherheit noch nicht einmal jedem so gut gefallen.
Grundsätzlich kann man an der Stelle sagen, die Daten nicht im Report zu speichern sondern diese dynamisch – wie oben angesprochen – aus einem ShapeFile oder von einem SQL Server zu laden ist wesentlich besser.
Hier zeichnet sich natürlich der Vorteil des SQL Servers gegenüber den ShapeFiles ab, da ich keiner direkten Größenbeschränkung unterliege. Habe ich meine Spatial Data im SQL Server gespeichert und nicht im Bericht eingebettet, so kommt meiner Beispielreport auf gerade einmal 20 KB.
Möchte ich Daten aber dennoch in meinem Bericht einbetten, so kann ich die einmal aus dem SQL Server geladenen Daten ganz einfach per Maus-Click wieder in meinen Bericht einbetten, womit der Bericht dann allerdings nur noch ca. 450 KB groß wird. Beim Einbetten der Daten wird nur der sichtbare Bereich der Daten eingebettet und dabei die Daten drastisch reduziert. Hat alleine Chile mit der stark zerklüfteten Küste aus dem ShapeFile heraus noch eine Größe von knapp 400 KB, so kommt das Land beim Einbetten der Daten aus dem SQL Server nur noch auf knapp 8 KB, die oben im Screenshot dargestellte Vergrößerung der Falklandinseln spart über 30 KB. Zu finden sind die entsprechenden Daten im übrigen jeweils in der RDL-Datei unter <VectorData>, im den darauf folgenden Tags <MapFields> sind auch die aus der DBF zugeordneten Daten wiederzufinden.
Um ShapeFiles in den SQL Server zu Laden kann man meine SSIS ShapeFileSource oder das Programm Shape2SQL von Morten Nielsen verwenden.
Nützliche Informationen zum Download von Spatial Data findet sich in meinem Blog Beitrag Geodaten – Teil 1 oder auch im Blog Beitrag “Addresses for geographical Data, ESRI-Shapefiles and other SQL Server geographical related stuff” meines PASS RGV Kollegen Andreas Wolter.
