2 MS SQL Datenbanken (Instanzen) mit 1 MS SQL 2008 R2 und 64-bit Problem (Scheinlösung?)

[Da-Paul-tum]

Hallo zusammen,
zum ersten Mal hier und froh, dieses Forum entdeckt zu haben. Ich bin totaler Datenbankanfänger und versuche gerade zwei MS SQL Express Server -Instanzen zu installieren, bzw ich habe sie installiert, es SCHEINT funktioniert zu haben und bin mir da unsicher (darum 'Scheinlösung?').

Von vorne:

Ich möchte 2 Instanzen verschiedener MS SQL Server Express Datenbanken auf meinem 64-bit Windows 11 PC installieren. Dies rührt daher, dass ich sie für zwei verschiedene WaWi-Systeme brauche, das sind also:

• SQL Server Express 2022
• SQL Server Express 2008 R2

Den 2008er brauche ich dringend für eine andere Software, die nun einmal leider nur darauf läuft - also kein Update. Beide sollen also parallel auf dem einen PC friedlich nebeneinander laufen.

Besser gesagt: laufen würden sie eher hintereinander- aber ich brauche die 2008er Version, um einen rel kleinen Datenbestand von einem gehosteten Server, der meine alte WaWi bedient, abzuholen und lokal zu speichern. Diese lokale Speicherung in dieser MS SQL Espress R2 DB brauche ich sowieso, auch später noch aus weiteren Gründen.

Tja, und es wäre ja viel zu einfach, wenn es da nicht wieder einige Issues bei der MS SQL Server Express 2008 R2- Installtion gäbe, wenn bereits eine MS SQL DB installiert ist:
Fehler bei Pfadänderung bei SQL Server 2008 Installation auf 64-bit Windows

Der zunächst vorgeschlagene Pfad war im Verzeichnis 'Microsoft SQL Server', in welchem aber bereits Unterverzeichnisse zum schon installierten MS SQL Server 2022 liegen. Ich hatte Bedenken, dass sich das irgendwie stören könnte und wollte einen anderen Ordner dafür wählen, im selben Überverzeichnis, also 'Microsoft SQL Server' --> 'MS SQL Server R2'
Es kommt dann eine Fehlermeldung (siehe dazu Link oben).

Inzwischen ist alles wohl erfolgreich installiert. Die von Microsoft vorgeschlagenen Lösungen konnte oder wollte ich nicht umsetzen- da es aber anscheinend um die Pfade beider Komponenten geht (es wird wohl eine 32-bit und eine 64-bit Komponente installiert), habe ich für beide (innerhalb der natürlich unterschiedlichen Programmordner) gleiche Pfade genommen. Das hat offenbar funktioniert.

Es kommt mir selbst komisch vor- aber ich hatte keine Lust mehr noch weiter zu probieren. Jedenfalls wurde am Ende eine erfolgreiche Installation gemeldet. Das würde bedeuten, dass ich damit einen dritten Lösungweg gefunden hätte, der auf der verlinkten MS-Seite nicht beschrieben ist- ich kann das irgendwie nicht glauben, also eine Scheinlösung?
Aber die Meldung nach der Installtion ist eindeutig, demnach ist auch die Installation der 2008er DB erfolgreich verlaufen...


Jetzt kommt noch die Einrichtung von HeidiSQL, was von JTL als Alternative für das MS SQL Server Management Studio vorgeschlagen wird. Da hakt es nun leider...

Hier die JTL-Guide Anleitung zur Einrichtung von HeidiSQL (Link)

Leider jedesmal mit Anmeldungstimeout bei mir ....


Wäre sehr dankbar für weiterführende Hilfe, leider dringend...

Gruß

Paul

 

[dabadepdu]

Wäre sehr dankbar für weiterführende Hilfe, leider dringend...

Wenn Du hier eine Antwort haben möchtest, musst Du wohl etwas konkreter mit DEINEN Installationsparametern werden.
Und ob HeidiSQL oder ein anderes Tool, Du musst die Verbindungsparameter kennen, sie angeben und dann bist Du drin.

(Spätestens) Wenn es mit Third Party Tools Probleme gibt, Bordwerkzeug nehmen, hier also:
sqlcmd(.exe)

Damit musst Du eine Verbindung hinkriegen. Wenn Du die Parameter alle richtig hast und die Verbindung klappt, dann kannst Du sie in anderen Tools nutzen.

Also, wirf sqlcmd an, gib deine Verbindungsparameter an und schau was passiert.
Wenn es nicht funktioniert:
poste deinen Befehl und die Fehlermeldung.

 

[MDDaniel]

Schau mal ob eine der SQL-Instanzen wirklich auf dem Port 1433 horcht. Womöglich ist noch nicht alles fertig konfiguriert.

 

[t-sql]

Jetzt kommt noch die Einrichtung von HeidiSQL, was von JTL als Alternative für das MS SQL Server Management Studio vorgeschlagen wird. Da hakt es nun leider...

Hier die JTL-Guide Anleitung zur Einrichtung von HeidiSQL (Link)

Leider jedesmal mit Anmeldungstimeout bei mir ....


Wäre sehr dankbar für weiterführende Hilfe, leider dringend...

Gruß

Paul

Schau einfach mal nach, ob deine Dienste zum SQL Server laufen. Es müssen ja mindesten zwei Express Instanzen laufen. Und bitte nimm kein HeidiSQL fürn SQL Server. Dafür ist das SSMS gemacht. Damit geht halt alles einzustellen und zu administrieren.

 

[Da-Paul-tum]

Schau einfach mal nach, ob deine Dienste zum SQL Server laufen. Es müssen ja mindesten zwei Express Instanzen laufen. Und bitte nimm kein HeidiSQL fürn SQL Server. Dafür ist das SSMS gemacht. Damit geht halt alles einzustellen und zu administrieren.

Ja, so läuft es auch:

Inzwischen ist alles wohl erfolgreich installiert. Die von Microsoft vorgeschlagenen Lösungen konnte oder wollte ich nicht umsetzen- da es aber anscheinend um die Pfade beider Komponenten geht (es wird wohl eine 32-bit und eine 64-bit Komponente installiert), habe ich für beide (innerhalb der natürlich unterschiedlichen Programmordner) gleiche Pfade genommen. Das hat offenbar funktioniert.

Aber anscheinend kennt hier niemand diesen Fehler bei der SQL 2008 R2 Installation im Zusammenhang mit 64 bit und Pfadänderung (siehe Link oben). Es würde mich wirklich sehr interessieren, ob ich da eine dritte Lösung gefunden habe.

Also, HeidiSQL lasse ich erstmal sein, ist auch nicht so wichtig. Da die MS SSMS auch nicht in allen Versionen zu allen SQL-Server-DBs passen, hatte ich mir zuerst die neueste SSMS Version 19.3 für den MS SQL Server 2022 installiert. Ich konnte diese DB (auf demselben Host, welches mein Notebook ist) erfolgreich mit dem Objekt Explorer verbinden- und dann auch den alten SQL Server 2008 R2, womit ich nicht unbedingt rechnete, weil MS sagt, dass dieser nicht mehr mit den neueren SQL Server Management Studios kompatibel sei (ab 18.3 glaube ich).
Ich kann dann im Objekt Explorer die Datenbank mit den entsprechenden Tabellen sehen; Datentransfers habe ich bis dato noch nicht ausprobiert.

Ich habe jetzt erstmal kein älteres SSMS installiert und würde gern wissen, ob jemand hier schon die Erfahrung gemacht hat- also relativ neues SQL Server Management Studio bei einem relativ alten MS SQL Server, der offiziell nicht mehr durch dieses SSMS unterstützt wird?

Ich hoffe, ich habe das soweit nachvollziehbar dargestellt.

Ich würde an der Stelle gern zum weiterführenden Vorhaben überleiten, denn diese Serverinstallationen sind ja kein Selbstzweck:

Ich möchte von einem Warenwirtschaftssystem auf ein anderes umsteigen. Beide nutzen als Datenbank einen MS SQL Server (die eine den MS SQL Server 2022 und die andere aus irgendwelchen Gründen den MS SQL Server 2008 R2). Wie Daten in Form von CSV aus einem SQL-Server transferiert werden, damit habe ich mich jetzt schonmal beschäftigt. Das Problem sehe ich vor allem in den Tabellen, wie diese angeordent sind. Ich bin totaler Newby in Datenbanken, würde dies aber dennoch gerne selbst machen. Keine Angst: ich habe keinen Onlineshop mit Schraubensortiment- es geht vielmehr um lediglich ca 40-50 Artikel sowie einem anonymen Kundenstamm. Wie stelle ich das am besten an?

Also, wirf sqlcmd an, gib deine Verbindungsparameter an und schau was passiert.

Ich bin leider sehr schlecht auf der Kommandozeile...

Schau mal ob eine der SQL-Instanzen wirklich auf dem Port 1433 horcht. Womöglich ist noch nicht alles fertig konfiguriert.

Wie macht man das, die Ports überprüfen? An der Firewall habe ich bis jetzt nichts verändert.

 

[t-sql]

Ja, so läuft es auch:



Aber anscheinend kennt hier niemand diesen Fehler bei der SQL 2008 R2 Installation im Zusammenhang mit 64 bit und Pfadänderung (siehe Link oben). Es würde mich wirklich sehr interessieren, ob ich da eine dritte Lösung gefunden habe.

Also, HeidiSQL lasse ich erstmal sein, ist auch nicht so wichtig. Da die MS SSMS auch nicht in allen Versionen zu allen SQL-Server-DBs passen, hatte ich mir zuerst die neueste SSMS Version 19.3 für den MS SQL Server 2022 installiert. Ich konnte diese DB (auf demselben Host, welches mein Notebook ist) erfolgreich mit dem Objekt Explorer verbinden- und dann auch den alten SQL Server 2008 R2, womit ich nicht unbedingt rechnete, weil MS sagt, dass dieser nicht mehr mit den neueren SQL Server Management Studios kompatibel sei (ab 18.3 glaube ich).
Ich kann dann im Objekt Explorer die Datenbank mit den entsprechenden Tabellen sehen; Datentransfers habe ich bis dato noch nicht ausprobiert.

Ich habe jetzt erstmal kein älteres SSMS installiert und würde gern wissen, ob jemand hier schon die Erfahrung gemacht hat- also relativ neues SQL Server Management Studio bei einem relativ alten MS SQL Server, der offiziell nicht mehr durch dieses SSMS unterstützt wird?

Also das SSMS 19.3 nicht mehr kompatibel zu SQL Server 2008 R2 sein soll hab ich bei MS nirgends gefunden. Wir benutzen SSMS 20 mit allen SQL Server, auch 2008 R2. Funktioniert tadellos. Ein altes SSMS mit neuen SQL Server wäre eine ganz schlechte Idee.

 

[MDDaniel]

Wie macht man das, die Ports überprüfen? An der Firewall habe ich bis jetzt nichts verändert.

Also ich machs entweder mit Kommandozeile oder mit Powershell
Hier ein Powershell Script zum reinkopieren und ausführen:

Get-NetTCPConnection | select Local*, Remote*, State,@{n="ProcessName";e={(Get-Process -Id $_.OwningProcess).ProcessName}},@{n="ProcessPath";e={(Get-Process -Id $_.OwningProcess).Path}} | ogv

Das zeigt dir die geöffneten Ports und Verbindungen und den entsprechenden Prozess mit zugehörigem Pfad an.
Je nach Konfiguration zeigt er dir auch die SQL Server an. Wenn da die SQL Prozesse fehlen kann es sein, dass diese nicht über TCP von einem anderen Rechner aus erreichbar ist/sind.

 

[t-sql]

Also ich machs entweder mit Kommandozeile oder mit Powershell
Hier ein Powershell Script zum reinkopieren und ausführen:

Get-NetTCPConnection | select Local*, Remote*, State,@{n="ProcessName";e={(Get-Process -Id $_.OwningProcess).ProcessName}},@{n="ProcessPath";e={(Get-Process -Id $_.OwningProcess).Path}} | ogv

Das zeigt dir die geöffneten Ports und Verbindungen und den entsprechenden Prozess mit zugehörigem Pfad an.
Je nach Konfiguration zeigt er dir auch die SQL Server an. Wenn da die SQL Prozesse fehlen kann es sein, dass diese nicht über TCP von einem anderen Rechner aus erreichbar ist/sind.

Alles net mehr nötig. Es geht ja, also passen die Ports.

 

[dabadepdu]

Ich bin leider sehr schlecht auf der Kommandozeile...

Wie macht man das, die Ports überprüfen? An der Firewall habe ich bis jetzt nichts verändert.

Das sind einfach grundlegende Vorgehensweisen. Besonders in Fällen wie Deinem, wo man jenseits einer Standardinstallation ist, macht es Sinn, mit einfachst möglichen Mitteln den Betriebszustand des Systems zu ermitteln. (Ob Deine Angabe mit SMSS Inkompatibilität stimmt oder nicht, es wäre ein typisches Argument für "Einfachheit"). Je kürzer oder simpler die Toolchain zum Server ist, desto mehr Fehlerquellen hat man von allein ausgeschlossen.
"Schlecht in der Kommandozeile" ist relativ, grafische Tools verschleiern häufig, was wirklich geschieht. Klar lässt sich ein Button einfach klicken. Alles funktioniert, solange man es mundgerecht serviert einsetzt. Scheint ja nicht genau auf Deinen Fall zu passen.
Um einen Verbindungsaufbau zu einem Server zu machen (egal ob DB oder anders), braucht man:
eine IP (echte IP/ DNS/ Localhost)
einen Port
Diese beiden Punkte kannst Du sogar ansprechen, wenn Du überhaupt keinen Server spezifischen Client installiert oder lauffähig hast.
Die IP sollte per ping.exe oder tracert.exe erreichbar sein. (es gibt dabei Einschränkungen, z.B. wenn VPN im Spiel ist, oder auch andere)
Der Port kann mit Telnet angesprochen werden, genauer, IP zusammen mit dem Port. Ping und Telnet sind beides Betriebssystem Bestandteile. Die Addressierung von Server Diensten per IP und Port zählt zu den Standards. Daher auch der Einsatz von Firewalls, die genau anhand dieser beiden Parameter den IP Verkehr beschränken.
Also wie schwer wird es sein einen Server mit 2 Parametern anzusprechen? Nicht sehr! Wie gut muss man in der Kommandozeile sein, um das hinzubekommen, nicht sehr!

sqlcmd –S tcp:192.168.1.42,1433

sqlcmd –S tcp:localhost,1433

sqlcmd –S tcp:192.168.1.42,1444

sqlcmd -S ComputerA,1433

sqlcmd -S ComputerA,1691

sqlcmd -S 127.0.0.1,1433

sqlcmd -S 127.0.0.1,1691

Dazu gibt es eine Menge Varianten. IP & Port sind die grundlegensten würde ich sagen. Das ist so einfach! Ein vollständiger Befehl, den Du einfach kopieren kannst und auf Deinem System nutzen.

Was @MDDaniel geschrieben hat, beinhaltet gleich die Suche nach geeigneten Ports. Das ist elegant, nach einer oder mehreren selbst durchgeführten Installationen aber eigentlich unnötig, weil der Installationsprozess die Festlegung des Ports beinhaltet. Und weil genau das im Zweifel gleich schief geht, wenn man für mehrere Installationen den gleichen Port wählt, dabei ist es egal, ob DB, ob MSSQL, Webserver oder sonstwas diesen Port nutzen. IdR erkennen Installationsprogramme aber auch, wenn ein Port bereits benutzt wird und melden es.

Also kurz: Du brauchst nicht mal sqlcmd, es reichen Betriebssystemprogramme, um festzustellen, ob Deine DB dort läuft, wo Du sie eingerichtet hast.

Alles net mehr nötig. Es geht ja, also passen die Ports.

Ich finde, es schadet nicht, ein paar Grundlagen zu kennen.

 

[Da-Paul-tum]

Phantastisch! Vielen Dank @dabadepdu , das ist wirklich sehr übersichtlich und verständlich
Und ich dachte immer 'Telnet' wäre eine Art Messengerdienst aus den Anfängen des Internet...

 

[dabadepdu]

Und ich dachte immer 'Telnet' wäre eine Art Messengerdienst aus den Anfängen des Internet

Telnet ist grob gesagt der Vorläufer von SSH, ein Kommunikationsprotokoll, mit ein paar Schwächen aus heutiger Sicht. Keine Authentifizierung, keine Verschlüsselung, nur Textübertragung….
Es reicht aber hier wie anderswo, die Strecke vom Client zum (Whatever)Server zu überprüfen.
Kommandozeile ist der einzige Weg, ein System verlässlich zu bedienen, zweifelsfrei zu supporten und das alles auch noch effizient.
Ein konkrete Befehl in der Kommandozeile, den man einfach kopieren und ausführen kann, ist 100% einsetzbar. Jede Beschreibung oder Erklärung, das Gleiche in einem GUI Tool zu machen, stinkt dagegen ab. Klick hier, dann gehe da hin, öffne den Objektbaum, schaue ob grün oder rot, wenn grün dann klick da, sonst da usw.
Das ist so ineffizient und missverständlich, dass man spontan sagen würde, dann schau ich mir das halt im Video an. Da geht der Spaß weiter, Bildschirmauflösung, Grundkonfiguration, Version, Sprache, alles ist variable und taugt nicht für eine 1:1 Nachvollziehbarkeit. Und natürlich die Frage: Gibt es davon ein Video oder hat man die Lust, sich das ganze Drumherum anzuschauen, nur um die eine wichtige Stelle zu entdecken.
Das ist auch der/ein Grund, warum professioneller Support bspw. im Datenbankbereich über Kommandozeile erfolgt. Das geht im Zweifel sogar in einem total abgeschotteten System.

Führe diesen Befehl aus (Text):
<Befehl>
kopiere die Rückgabe (Text) und schicke sie zurück an den Support.
Das wird solange wiederholt, bis das Problem erkannt und gelöst ist.
Kommandozeile gibt Dir mehr Kontrolle und Verständnis über/von Deinem System.

Ein anderer Aspekt ist vielleicht noch schlimmer, zumindest dann, wenn wie in Deinem Fall, nicht mehr nur ein System betreut werden muss. GUI skaliert in der Bedienung nicht. Die gleiche Befehlsfolge (Script) für verschiedene Systeme kann innerhalb von Sekunden aufgerufen und abgearbeitet werden. Bei einer Durchführung über GUI steigt bestenfalls die Geschwindigkeit der Mausbedienung durch Training. Ab da braucht man Hilfstools wie Mausrecorder oder so was.

Der Vollständigkeit halber: Die Geschwister von Kommandozeile sind Konfigurationsdateien und Logfiles.

 

[ukulele]

Hab das hier mal überflogen, hier mein Senf.

Wenn du MSSQL installierst wird i.d.R. unterhalb eines Pfades immer noch ein Pfad mit der Versionsnummer angelegt, so etwas wie MSSQL10.SQLEXPRESS für SQL 2008 und MSSQL16.SQLEXPRESS für SQL 2022. Demnach müsste man beide Versionen im selben Pfad betreiben können.

Du solltest dir Gedanken machen ob du dieses Konstrukt wirklich so betreiben willst. SQL 2008 R2 wird seit 2019 nicht mehr supported. Wenn du nur an alte Daten ran musst kannst du die Datenbank-Dateien i.d.R. auch an einen neuern SQL Server anhängen und kommst dort in die Datenbanken. Wenn du noch eine alt-Anwendung starten können musst bestünde auch die Chance das die alte DB an einem neueren DBMS läuft. Die Verbindung zwischen Software und Datenbank ist sehr gut abwärtskompatibel, genau wie das SSMS.

Abgesehen davon willst du da drei verschiedene DBMS + vermutlich diverse Software auf einem Client OS laufen lassen. Das kann sehr viele Fehlerquellen bedeuten und administrativ würde man das heute nicht unbedingt machen. Mittlerweile wird sowas eher virtualisiert und zerlegt auf einzelne VMs damit man die Installation sauber trennen kann.

Ich habe mal einenen JTL Datenbestand "analysiert", das war kein Spaß. Diese Software arbeitet mit Daten und mit der Sicherheit irgendiwe nach dem Prinzip Augen zu und durch aber das scheint in der Branche üblich...