Zugriff auf MS SQL Server 6.5 unter Windows 10

[mionde]

Hallo zusammen,

kennt jemand eine Möglichkeit bzw. einen Treiber mit welchem man auch unter Windows 10 noch auf einen SQL Server 6.5 zugreifen kann?
An Windows XP Rechnern kann ich über den ODBC Treiber "SQL Server" Datei "SQLSRV32.DLL" Version "2000.85.1132.00" zugreifen.
Unter Windows 10 ist die Version "10.00.17134.01" installiert. Diese mag SQL Server Versionen unter 7.0 nicht mehr.

[Bernhard Geyer]

WOW. Wer betreibt den solche antiken SQL Server Versionen noch?

Also ich würde sagen: VM und dort Win7 installieren und dann von dort zugreifen.

Alternativ Anwendung umschreiben und eine Delphi-Komponente für den Zugriff nutzen:
https://www.devart.com/sdac/

[HolgerX]

Hmm..

Kannst ja mal das testen:

https://virtuallyfun.com/wordpress/2...on-windows-10/

;)

[mkinzler]

Zitat:

Alternativ Anwendung umschreiben und eine Delphi-Komponente für den Zugriff nutzen:
https://www.devart.com/sdac/

Geht wohl auch erst ab der 7er.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1430892)

Zitat:

Alternativ Anwendung umschreiben und eine Delphi-Komponente für den Zugriff nutzen:
https://www.devart.com/sdac/

Geht wohl auch erst ab der 7er.

Hab ich nicht drauf geschaut.
Für uns ist die älteste (offiziel) Unterstützte Version die 2008er.
Und viele Kunden steigen gerade um auf eine neuere Version, da es für dies auch schon kein Updates mehr von MS gibt.

[mionde]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1430889)

WOW. Wer betreibt den solche antiken SQL Server Versionen noch?

Es handelt sich um eine Steuerung einer Produktionsanlage, welche Ihre Logfiles darin speichert.
Ein Ersatz der Steuerung wird leider erst in 2-3 Jahren möglich sein (Budget).

[TigerLilly]

Aber den SQL Server auszutauschen sollte doch kein Problem sein.
Du kannst die Express Edition nahmen, die ist kostenfrei und kann auch im Netz eingesetzt werden.
- Backup der alten DB
- Win10 Rechner mit SQLExpress 2014
- Backup einspielen
- Services stoppen
- Rechner auf alten Namen umbenennen

Vielleicht musst du bei den Credentials noch ein wenig rumfummeln:
https://www.fileformat.info/tip/micr...rphan_user.htm

[TigerLilly]

Nachtrag: In einem anderen Thread ging es um State-Of-The-Art in IT-Anwendungen. Das gilt auch hier: Im Zweifel zahlt zB keine Versicherung, wenn so alte Software eingesetzt wird. Da wird aus leichter Fahrlässigkeit schnell grobe Fahrlässigkeit.

[p80286]

Nun ja, wenn das Budget dafür nicht vorhanden ist, machst Du erst einmal nichts. Wenn's dann kracht, hättest Du natürlich Dich wesentlich mehr engagieren müssen. Wie Du es drehst und wendest, solange Du kein Verantwortlicher bist, wirst Du zur Verantwortung gezogen.

Gruß
K-H

[jobo]

Also muss es wirklich ne 6.5er sein? Einfach mal was höheres (7er wurde schon genannt) hinstellen und ein Connect versuchen.
Und "Logfiles" im SQL Server, das ist auch gediegen. Werden die Aufbereitet zum Browsing / Analyse .. ?
Gibt es vielleicht irgendwo einen "INI Schalter" ala "logDirection=FILE/SQL"?

Eine VM mit entsprechend alter Software wurde ja auch schon vorgeschlagen.

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

[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:

Zitat von jobo (Beitrag 1430918)

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:

Zitat von TigerLilly (Beitrag 1430912)

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:

Zitat von mionde (Beitrag 1430927)

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:

Zitat von TigerLilly (Beitrag 1430928)

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. :pale:
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.