Kategorie: SQL Server und Co.

Wer für einen Kunden Datenbanken auf Basis von SQL Server programmiert, tut gut daran, nicht am offenen Herzen zu operieren, sprich: Änderungen an einer Datenbank erst an einer Kopie dieser Datenbank auszuprobieren. Wer seine eigenen Datenbanken auch auf dem SQL Server verwaltet, gerät da schon leichter in Versuchung, mal eben schnell eine Änderung am laufenden Produktivsystem durchzuführen. Auch wenn man meint, man wüsste genau, was man tut, macht es doch Sinn, zumindest eine Sicherheitskopie der zu bearbeitenden Datenbank anzulegen. Nun bietet der SQL Server keine einfache Lösung zum Herstellen einer Kopie á la Strg + C, Strg + V an. Allerdings wird man dennoch schnell fündig, wenn man nach einer entsprechenden Lösung sucht – in diesem Fall allerdings nur in höheren SQL Server-Editionen, also nicht in der Express Edition.

Die SQL Server Data Tools sind eine Erweiterung für Visual Studio, mit denen wir interessante Aufgaben rund um die Verwaltung von SQL Server-Datenbanken erledigen können, die teilweise nicht mit dem SQL Server Management Studio möglich sind. Dazu gehört unter anderem das Vergleichen der Schemata zweier Datenbanken. Diese werden jedoch nicht zwingend direkt mit Visual Studio installiert, sodass wir uns in diesem Beitrag kurz ansehen, wie wir dies nachholen können – bevor wir uns in weiteren Beiträgen ansehen, was wir mit den SQL Server Data Tools alles erledigen können.

Wer schnell die Tabellen einer Access-Datenbank zum SQL Server migrieren möchte, kann dazu ein kostenloses Tool von Microsoft nutzen: Den SQL Server Migration Assistant, in diesem Fall in der Ausführung für Access. Wie wir die Tabelle einer Access-Datenbank zum SQL Server übertragen und gleichzeitig auch noch die passenden Verknüpfungen für den Zugriff auf diese Datenbank erstellen, zeigen wir in diesem Beitrag. Dabei nutzen wir die schnellste zur Verfügung stehende Methode, nämlich den Migration Wizard, ein Assistent im Assistenten. Im besten Fall kann man danach direkt von der Access-Datenbank auf die Daten im SQL Server-Backend zugreifen. Gegebenenfalls sind noch Vor- und Nacharbeiten erforderlich, um die kümmern wir uns jedoch in eigenen Beiträgen.

Uns erreichen immer mehr Anfragen, wie man seine Datenbank ins Internet bringt. Oder, um genauer zu sein: Wie man diese so verfügbar macht, dass man von mobilen Geräten über das Internet darauf zugreifen kann. Ob man sich nun von einem Notebook aus mit der Datenbank verbindet oder ob man eine alternative Technik wie eine Webseite dafür nutzt. Und gleichzeitig auch noch vom heimischen Rechner oder aus dem Büro über das Access-Frontend auf die Daten zugreifen kann. Also schauen wir uns einmal die Voraussetzung dazu an – einen über das Internet erreichbaren Rechner. Hier haben wir verschiedene Möglichkeiten. Wir können einen Cloud-Service wie den von Microsoft nutzen, aber wir können uns auch einen eigenen Server mieten, auf dem wir tun und lassen können, was wir wollen – SQL Server installieren, Webseiten anlegen et cetera. Wir schauen uns den letzten Punkt an, da er uns maximale Freiheit bietet, aber auch maximale Verantwortlichkeit einfordert: Das Mieten eines Webservers (hier virtuell) und die Verwendung von SQL Server 2022 Express auf diesem Webserver. In diesem ersten Teil schauen wir uns erst einmal an, wir einen Webserver mieten und diesen erstmalig mit der Remotedesktopverbindung öffnen und anzeigen können.

Uns erreichen immer mehr Anfragen, wie man seine Datenbank ins Internet bringt. Oder, um genauer zu sein: Wie man diese so verfügbar macht, dass man von mobilen Geräten über das Internet darauf zugreifen kann. Ob man sich nun von einem Notebook aus mit der Datenbank verbindet oder ob man eine alternative Technik wie eine Webseite dafür nutzt. Und gleichzeitig auch noch vom heimischen Rechner oder aus dem Büro über das Access-Frontend auf die Daten zugreifen kann. Also schauen wir uns einmal die Voraussetzung dazu an – einen über das Internet erreichbaren Rechner. Hier haben wir verschiedene Möglichkeiten. Wir können einen Cloud-Service wie den von Microsoft nutzen, aber wir können uns auch einen eigenen Server mieten, auf dem wir tun und lassen können, was wir wollen – SQL Server installieren, Webseiten anlegen et cetera. Wir schauen uns den letzten Punkt an, da er uns maximale Freiheit bietet, aber auch maximale Verantwortlichkeit einfordert: Das Mieten eines Webservers (hier virtuell) und die Verwendung von SQL Server 2022 Express auf diesem Webserver.

Uns erreichen immer mehr Anfragen, wie man seine Datenbank ins Internet bringt. Im den ersten beiden Teilen dieser Beitragsreihe mit dem Titel „SQL Server im Web, Teil 1: Webserver“ und „SQL Server im Web, Teil 2: SQL Server 2022 Express installieren“ haben wir uns angesehen, wie wir einen Webserver beziehungsweise einen Virtual Private Server mieten und darauf den SQL Server 2022 Express installieren. Im dritten Teil dieser Beitragsreihe installieren wir nun das SQL Server Management Studio auf unserem Webserver. Damit wollen wir die Administration des SQL Servers direkt von seinem Serverrechner aus ermöglichen, auf den wir zu diesem Zweck über die Remotedesktopverbindung zugreifen.

In den ersten drei Teilen dieser Beitragsreihe haben wir einen Webserver aufgesetzt, den SQL Server installiert und das SQL Server Management Studio hinzugefügt. Damit können wir über die Remotedesktopverbindung auf den Server zugreifen und dort den SQL Server administrieren. Wir wollen aber nicht immer die Remotedesktopverbindung nutzen, sondern direkt von unserem lokalen Rechner aus auf den SQL Server auf dem Webserver zugreifen. Das wird schon etwas spannender als die Einrichtung und der Zugriff vom SQL Server Management Studio direkt auf dem Webserver. Warum? Weil wir unterschiedliche Ports verwenden müssen und diese je nach Anwendungsfall standardmäßig freigeschaltet sind oder auch nicht. Was es damit auf sich hat, erläutern wir in diesem Beitrag.

Die einfache Migration der Tabellen einer Datenbank von Access zum SQL Server ist meist schnell erledigt. Der SQL Server Migration Assistant (SSMA) leistet gute Arbeit und schnell landen alle Tabellen in der SQL Server-Datenbank – samt Erstellung entsprechender Tabellenverknüpfungen im Access-Frontend. Damit lässt sich erst einmal arbeiten, da die Verknüpfungen Lesen und Schreiben der Daten wie gewohnt zulassen. Früher oder später wird man jedoch auf Abfragen im Access-Frontend stoßen, die schlicht zu langsam sind. Und hier kann der SQL Server sein wahres Potential ausspielen: Zum Beispiel, indem wir dort eine Stored Procedure (Gespeicherte Abfrage) anlegen, welche die Abfrage für uns direkt auf dem SQL Server ausführt, was viel schneller gehen wird. Und genau das ist Thema dieses Beitrags: Wie bekommen wir eine mehr oder weniger komplizierte Abfrage als Stored Procedure zum SQL Server und rufen diese von der Access-Datenbank aus auf?

Wer wie ich den SQL Server auf dem gleichen Desktop-Rechner installiert hat, auf dem er auch arbeitet, macht sich über den Einsatz im Netzwerk keine großen Gedanken. Neulich aber habe ich einen neuen Rechner aufgesetzt und es fehlte schlicht die Zeit, auch den SQL Server und die damit verwalteten Datenbanken auf dem neuen Rechner zu installieren. Also dachte ich, dass ich einfach über das Netzwerk auf den SQL Server des alten Rechners zugreifen könnte. Das geht jedoch nicht ohne Weiteres und je nach Konfiguration ist der eine oder andere Schritt nötig. Also schauen wir uns an, was bei mir zum Erfolg geführt hat.

Im Beitrag „SQL Server: Vollsicherung und Wiederherstellung“ haben wir uns angesehen, wie wir eine Sicherung einer SQL Server-Datenbank durchführen können. Wenn wir uns eine solche Sicherungsdatei im Texteditor ansehen, stellen wir schnell fest, dass ein Backup, wie wir es in diesem Beitrag vorgestellt haben, nicht verschlüsselt abgelegt wird, sondern den unverschlüsselten Text enthält. Liegen solche Daten im heimischen Server, der durch das Windows-Sicherheitssystem vor Zugriffen Fremder gesichert ist, mag das praktikabel sein. Sollen jedoch Kopien von diesen Daten angelegt werden, die nicht auf diese Weise gesichert sind, ist eine zusätzliche Verschlüsselung nötig. Das verschlüsselte Sichern einer SQL Server-Datenbank ist wesentlich aufwendiger als die einfache Sicherung. Deshalb schauen wir uns dies Schritt für Schritt im vorliegenden Beitrag an.