Kategorie: SQL Server und Co.

Anlage-Felder erlauben es seit Access 2010, Bilder und andere Dateien direkt in -Access-Tabellen zu speichern. Sie bieten ein praktisches Popup-Menü, mit dem man die enthaltenen Dateien verwalten kann. Enthält ein Anlage-Feld Bilddateien, können diese mit dem Bild-Steuerelement von Access direkt in Formularen und Berichten angezeigt werden. Wenn man seine Tabellen zum SQL Server migrieren möchte, wird dies jedoch zu einem Problem: Im SQL Server gibt es nämlich kein Pendant zum Anlage-Feld, sondern nur Alternativen wie beispielsweise den varbinary(max)-Datentyp. Damit können wir zwar die Dateien im binären Format im SQL Server speichern, aber rundherum ergeben sich einige Fragen: Wie zeige ich Bilddateien an, die in einem solchen Feld gespeichert sind? Wie gehe ich mit Anlage-Feldern um, die nicht nur eine Anlage enthalten? All dies erläutern wir in diesem und weiteren Beiträgen.

Im Beitrag „Anlage-Feld zum SQL Server migrieren“ (www.access-im-unternehmen.de/1542) haben wir gezeigt, wie Inhalte von Anlagefeldern einer Access-Datenbank in ein varbinary(max)-Feld einer SQL Server-Datenbank übertragen werden können. Dort sind wir davon ausgegangen, dass jedes Anlagefeld immer nur eine Datei enthält, was in vielen Fällen ausreichend ist. Was aber, wenn der Entwickler das Anlagefeld für mehrere Dateien vorgesehen hat – beispielsweise, um ein oder mehrere Produktbilder zu einem Produkt zu speichern? In diesem Fall müssen wir umdenken, denn wir können optimalerweise immer nur eine Datei in einem varbinary(max)-Feld speichern. Zum Speichern mehrerer Dateien müssen wir uns also einen Workaround überlegen. Wie dieser aussieht, schauen wir uns im vorliegenden Beitrag an.

Wie man Bilder in Access speichert, ist seit der Version 2010 eindeutig vorgegeben – nämlich in Anlagefeldern. Die Inhalte dieser Felder können auch leicht im Bild-Steuerelement angezeigt werden, dazu braucht man nur eine einfache Bindung an das entsprechende Feld. Allerdings bietet der SQL Server keinen solchen Datentyp, sondern nur verschiedene Alternativen. Dabei handelt es sich beispielsweise um den Datentyp VarBinary(max) oder um FILESTREAM. Die erstgenannte Alternative schauen wir uns im vorliegenden Beitrag an.

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.