![\"Menüeintrag](\"..\/fileadmin\/_temp_\/2019_06\/pic_201_001.png\")
<\/p>\nWenn Sie mit Access arbeiten, um Datenbankanwendungen zu programmieren, und damit Berichte entworfen haben, wissen Sie, wieviel Arbeit hinter einem Bericht stecken kann. Umso ärgerlicher, wenn man die Anwendung dann nach .NET migrieren möchte und die ganze Arbeit nochmal erledigen muss. Doch das muss gar nicht sein, denn: Die Microsoft Reporting Services Projects erlauben auch den Import von Berichten aus bestehenden Access-Datenbanken. Ob diese Funktion Arbeit bei der Migration spart und wie sie überhaupt funktioniert, klärt dieser Artikel.<\/b><\/p>\n
Beim Herumspielen mit den Microsoft Reporting Services Projects schaute ich auch einmal in das Untermenü Projekt<\/b>, um sicherzugehen, dass ich keine Möglichkeit übersehe, einen neuen Bericht anzulegen. Dort finde ich zu meiner Überraschung den Eintrag Berichte importieren<\/b>, der noch überraschender den Befehl Microsoft Access… <\/b>lieferte (siehe Bild 1). Und warum soll das nicht funktionieren Immerhin gibt es in Access-Berichten auch nur einfach Steuer-elemente, die an bestimmten Positionen platziert sind und die, wenn es sich um gebundene Steuer-elemente handelt, eine Eigenschaft mit dem Verweis auf ein Feld der Datensatzquelle des Berichts oder einen berechneten Ausdruck enthalten. Kompliziert könnte es werden, die verschiedenen Berichtsbereiche und Gruppierungen von Access in einen Reporting Services-Bericht zu überführen, aber auch das sollte möglich sein. Schauen wir uns doch einfach an, was passiert!<\/p>\n
<\/p>\n
Bild 1: Menüeintrag zum Importieren von Berichten aus Access-Datenbanken<\/span><\/b><\/p>\n Wichtig ist natürlich, dass wir die Datenquelle für den Bericht, den wir importieren wollen, in geeigneter Form bereitstellen können. Da die hier verwendete Software zur Reportgenerierung auf den SQL Server Reporting Services basiert, müssen die Daten logischerweise in einer SQL Server-Datenbank bereitgestellt werden. Sollten die Daten bisher nur in einer Access-Anwendung vorliegen, müssten wir diese also zuvor noch migrieren. Das ist aber kein Problem, denn wir haben ja in den vergangenen Ausgaben Code programmiert, mit dem wir ein Entity Data Framework auf Basis des Datenmodells einer Access-Datenbank erstellen können. Dieses wiederum können wir zur Generierung der entsprechenden SQL Server-Datenbank verwenden. Die Vorbereitung sollte also nur wenige Minuten in Anspruch nehmen. Und vielleicht ist das sogar noch nicht einmal notwendig und die Daten werden beim Import direkt mit importiert. Probieren wir es aus!<\/p>\n Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>Vorbereitung<\/h2>\n
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Visual Basic Entwickler<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 200 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t