Zugriff auf MS SQL Server 6.5 unter Windows 10

[TigerLilly]

6.5 hat seit ca. 2004 end-of-support erreicht.

Aber so geht es oft:
Es läuft. Es läuft auf einem alten Rechner. Es läuft auf einem alten virtualisierten Rechner. Und irgendwann läuft es nicht mehr.

[mionde]

Zitat von jobo:

Aufgrund der geschilderten Sachlage gehe ich davon aus, dass keine oder keine gute Kommunikation zum Hersteller existiert...

Du hast recht, den Hersteller gibt es in der Form nicht mehr.

Zitat von TigerLilly:

Aber den SQL Server auszutauschen sollte doch kein Problem sein.

Diese Idee hatte ich auch schon, aber ich kann nicht sicherstellen,
dass die Originalsoftware auch auf eine neuere Version vom SQL Server zugreifen kann.

Ich verstehe eure Bedenken Arbeit in ein veraltetes System zu stecken, mir geht es ja genauso.
Aber der Austausch bzw. die Modernisierung einer Steuerung von Produktionsanlagen ist leider oft nicht so einfach möglich.

[TigerLilly]

Zitat von mionde:

Diese Idee hatte ich auch schon, aber ich kann nicht sicherstellen,
dass die Originalsoftware auch auf eine neuere Version vom SQL Server zugreifen kann.

Der Server wird nicht das Problem sein, eher der Client-Datenbanktreiber. Gibt es da noch eine BDE oder wie geht die Software an den Server?
Kannst du da beliebig viel herumprobieren?

[jobo]

BDE?! Schreck lass nach ..

Vielleicht wird ja sogar ein ODBC Treiber genutzt (direkt oder über BDE), damit hätte man jedenfalls einigen Spielraum, da der ODBC Treiber "huckepack" auf ein OLEDB o.ä. eines neueren Servers zugreifen könnte. (VM/Hardware, OS und SQL Server müssen ja gar nicht auf dem Originalgerät liegen, sie müssen nur von dort ansprechbar sein)

[mionde]

Zitat von TigerLilly:

Der Server wird nicht das Problem sein, eher der Client-Datenbanktreiber. Gibt es da noch eine BDE oder wie geht die Software an den Server?
Kannst du da beliebig viel herumprobieren?

Die Software ist leider nicht von mir. Aber sie ist definitiv keine Delphi Anwendung, somit scheidet die BDE aus (nicht installiert).
Wenn ich mir die ODBC-Einstellungen auf dem Rechner (Windows NT) ansehe,
macht es für mich den Eindruck, als würde das Programm direkt zugreifen.
Es sind zumindest keine DSN für den Server hinterlegt.

Rumprobieren kann ich theoretisch schon, meine Sorge ist nur, dass mir das Ding um die Ohren fliegt und dann die Produktion steht.
Daher wollte ich den Weg mit dem geringsten Eingriff auf Seite des Steuerungsrechners wählen,
eben einen Zugriff von außen. Aber wenn es keinen Treiber gibt, muss eben ein Umweg her...

Ich werde jetzt eine VM mit einem OS welches die Treiber für SQL Server 6.5 unterstützt aufsetzen.
Dort lasse ich dann eine Anwendung laufen, welche mir die benötigten Daten auf einen aktuellen SQL Server kopiert. Ist zwar etwas umständlicher und fehleranfälliger, aber ich denke der sicherste Weg ohne viele Änderungen am Bestandsserver.

Vielen Dank für eure Vorschläge und Antworten!
Falls jemand noch weiter Infos hat, bitte gerne posten...

[jobo]

Was ich nun nicht mehr so ganz verstehe, ist die Frage, was überhaupt mit einem solchen Treiber geschehen soll.
Ist der Treiber (und Zugriffsform) am Ende egal(Hauptsache man kommt auf diese DB)? Wahrscheinlich nicht.
Und wer sagt Dir, wenn Du keine DSN findest, was es überhaupt sein soll und was folglich installiert sein müsste? Bspw. auch wenn keine DSN zu finden ist, kann es trotzdem ODBC Zugriff sein, gleiches gilt wahrscheinlich für die meisten andere Treiber.

[generic]

Ich werfe mal eine ganz andere Idee in den Raum.
Lass das mit den Treiber.

Klick dir mit Delphi ein REST-Service zusammen, welcher die Logtabelle via HTTP(S) liefert.
Das installierst du einfach auf den Datenbankserver-Rechner.

Deine Win10 Clients können dann via HTTP sich die Daten holen.

[jobo]

Dieser Vorschlag verwirrt mich auch.
Ich dachte es geht darum, bei einem gegebenen, fest verdrahten System die Plattform zu aktualisieren und eine lauffähige Kombination zwischen App und Server hinzubekommen.

Aber es geht bloß um das Auslesen eines alten Servers von einem neuen OS aus?
Mal als grobe Idee: Installiere Dir irgendwo (wo eine möglichst alte Plattform "rumfliegt") einen möglichst alten MS SQL Server, z.B. 7. Von dem aus machst Du einen (oder soviel Du brauchst) Datenbank Link auf das/die 6.5 Zielsystem(e).

Ehrlich gesagt, ich weiß nicht mal ob es zu dem Versionsstand schon DB Link (linked Server) gab bei MS SQL, also es ist ein Schuss ins Blaue, aber der Hintergrund des Vorgehens ist:

Es ist häufig so, dass die Serveranbieter die Serverfunktion selbst (hier DB Link inkl. Connectivity) länger unterstützen, als die Client-Technik. Das ist sozusagen ein Geschenk / Hintertürchen für verlängerten Support/kritische Anwendungen. Man kommt normalerweise nicht einfach so darauf, dass die benötigte Clientfunktion noch existiert, wenn der Client selbst ein Server ist. Vielleicht gibt es das so auch bei MS SQL.

Du kannst es entweder schnell und schonend (Das Prod System bleibt von einer Installation unberührt) ausprobieren, wenn Du die Software verfügbar hast und das flott installierst oder die Idee mal im Netz recherchieren (gibt es Belege, dass das geht).

Ok, das Ergebnis: Du hast auf einem neueren Server die Daten im Zugriff und musst das Auslesen darauf schwenken. Es kostet natürlich eine Lizenz Server und OS, wie immer bei denen.

Ansonsten ist der Vorschlag von Generic natürlich in diversen Varianten machbar, wenn Du eine EXE auf dem alten Server mit MSSQL Zugriff zum Auslesen "einschleusen" kannst. Ob Rest, CSV, XML, Log Text usw als Export, egal, solange Du nicht auf den SQL Serverzugriff mit weiterer Software angewiesen bist. Falls das der Fall ist, würde ich der Idee mit dem Server/Server Connect nachgehen.