Neu Frage zur Installation der JTL-Wawi-Datenbank auf einem MS-SQL-Server unter CentOS

[TDS2018]

Guten Abend,

ich habe bislang Erfahrung in der Installation von JTL-Wawi auf Einplatzsystemen und im Netzwerk, wobei der SQL-Server auf Server 2019 lief. Nun wollte ich mich an die erste Installation der JTL-Wawi-Datenbank auf einem MS-SQL-Server auf Linux herantasten. Ich habe habe das Forum nach einer Installationsanleitung gesucht und nichts gefunden. Bevor ich mich tiefer mit der Linux-Version des MS-SQL beschäftige, dachte/hoffte ich, daß es bereits eine erprobte Anleitung bzw. Scripte/Tools wie bei der Windows-Version gibt. Daher meine Frage, ob dies hier schon irgendwo gepostet und falls nicht, hier zusammengetragen werden kann:

Zielsetzung:
a) JTL Wawi-Clientsoftware auf Win10-Rechnern
b) CentOS 8 Server mit MS-SQL-Server
c) Erstellung der JTL-Wawi-Datenbank auf dem MS-SQL-Server und
d) Anbindung der JTL-Clients

Gegenwärtig habe ich a) und b) erledigt. Über die JTL-Datenbankverwaltung habe ein neues Profil erstellt und mich mit dem SQL-Server verbunden. JTL meldet, daß keine Datenbank vorhanden ist und fragt, ob diese erstellt werden soll . Danach gibt es eine Fehlermeldung (s. Screenshot) und JTL stürzt ab. Es ist nicht möglich, sich detaillierte Informationen anzeigen zu lassen oder das Fehlerprotokoll zu speichern. JTL kann nur noch über den Taskmanager beendet werden.

Wie geht es jetzt weiter; existiert ein Script, der auf dem SQL-Server aufgerufen wird und die Datenbank erstellt und wenn ja, wo kann man diesen herunterladen oder muß man die Datenbank "zu Fuß" erstellen?

 

[csaeum]

Ich arbeite hier nur mit Docker und wie schon im anderen Beitrag geschrieben werde ich es selbst nochmal testen und vielleicht kann ich dir dann helfen.

 

[csaeum]

Wie sind deine Rechte unter deinen MSSQL Verzeichnissen und was ist beim anlegen der DB für Verzeichnisse angegeben.

 

[TDS2018]

MSSQL hat standardmäßig 600 eingetragen, ich habe jetzt testweise 777 eingetragen. Nachdem ich mit JTL-Datenbankverwaltung keinen Erfolg hatte, installierte ich MS SQL Management Studio. Mit Filezilla kopierte ich das mit JTL erstellte Backup in das Verzeichnis /var/opt/mssql/backup. Mit SMSS konnte ich kein Restore machen, da es einen Fehler gab. Also erstellte ich mit SMSS ein neues Backup, das interessanterweise doppelt so groß war, wie das mit JTL-Datenbankverwaltung erstellte. Aber auch das konnte ich mit SMSS nicht zurückspielen. Erst manuell hat es funktioniert:

RESTORE DATABASE YourDB
FROM DISK = '/var/opt/mssql/backup/YourDB.bak'
WITH MOVE 'YourDB' TO '/var/opt/mssql/data/YourDB.mdf',
MOVE 'YourDB_Log' TO '/var/opt/mssql/data/YourDB_Log.ldf'
GO

Es hat noch das Problem gegeben, daß der MSSQL sich unter Linux wohl standardmäßig mit der Sortierung Latin1_General_CP1_CI_AS installiert. Wir benötigen jedoch Latin1_General_CI_AS. Also muß man noch eingeben:
systemctl stop mssql-server
/opt/mssql/bin/mssql-conf set-collation
Latin1_General_CI_AS
systemctl start mssql-server
Das hat soweit ohne Fehler funktioniert. Über JTL-Wawi-Datenbankverwaltung wollte ich eine neue Verbindung einrichten wollen und es gab einen Fehler
Über die JTL-Datenbankverwaltung funktionieren Funktionen wie Datenbankbereinigung etc. Ich habe auch die Verbindung über odbcad32.exe aufgebaut und bekam den gleichen Fehler wie beim Verbindungsaufbau über JTL. MIt der aktualisierten Version des ODBC Drivers ( https://download.microsoft.com/down...635646DA801E/en-US/17.5.2.1/x64/msodbcsql.msi ) ist dieser Fehler weg und ich kann dann auch mit JTL eine Verbindung mit admin/pass aufbauen aber danach kommt wieder der gleiche Fehler wie auf dem Bild oben. Es scheint was mit TLS zu tun zu haben und jetzt finde ich auch noch diesen Beitrag

https://forum.jtl-software.de/threads/login-zur-datenbank-fehler-772.137634/

eines Users, der das gleiche Problem hatte aber leider nicht genau weiß, woran es lag. Ich will morgen sehen, ob ich mehr Erfolg habe, sonst mache ich bei JTL ein Ticket auf.

 

[Enrico W.]

Bitte beachtet die Systemvoraussetzungen! https://guide.jtl-software.de/jtl-w...ungen-fuer-den-datenbankserver-ms-sql-express


Daher muss ich da auch ganz klar sagen "da ist unser Support raus aus der Nummer". Tut mir leid.

 

[TDS2018]

@Enrico W.
Einerseits verstehe ich, daß JTL SQL-Server unter Windows unterstützt und andererseits verstehe ich nicht, daß man Linux meidet. Das macht auf mich den Eindruck, als wenn Hamilton nur Mercedes fahren würde und auf keinen Fall Ferrrari, und damit den Eindruck hinterlassen würde, Ferrari wäre für ihn ein Buch mit sieben Siegeln.

Ich hänge nochmal die letzte Fehlermeldung an und breche die einzelnen Fehlermeldungen unter Zuhilfenahme von Google auf:



1) SQLState: 01000
Der SQLSTATE = 01000-Teil des Fehlers zeigt an, dass die ODBC-Verbindung zwischen dem Client und der Datenbank unterbrochen wurde.
2) SQL Server Error: 772
Der SQL Server-Fehler 772 wird häufig ausgelöst, während eine Anwendung oder ein ODBC eine Verbindung zum SQL Server herstellt. Die Hauptgründe für den Fehler sind die Verwendung alter ODBC-Treiber- und Verschlüsselungsmethoden des Clients.
3) SQLState: 08001
Meistens tritt beim Erstellen einer ODBC-Verbindung unter Microsoft SQL der Fehler SQLStateServer-Verbindung fehlgeschlagen 08001 auf.
4) SQL Server Error: 18
Der SQL Server-Fehler 18 wird ausgelöst, wenn Benutzer aufgrund von Problemen mit der Verschlüsselung oder der TLS-Version eine Verbindung zum SQL Server herstellen.

Mit diesem Ergebnis gehe ich meiner Vermutung nach, daß die Ursache bei meinem Windows-Rechner liegt: die einzelnen Fehler deuten auf die ODBC-Verbindung deuten und auf ein Verschlüsselungsproblem.

Ferner unterstelle ich, daß dieser lokale Fehler beim Verbindungsaufbau zu einem x-beliebigen MS SQL-Server enststehen kann, unabhängig von der Plattform. Da ich zudem mit dem aktuellen SSMS vollständig auf die SQL-Datenbank zugreifen kann, untermauert es meine Vermutung eines lokalen Problems.

Auf CentOS 8 läuft Microsoft SQL Server 2019 (RTM-CU8) (KB4577194) - 15.0.4073.23 (X64)

Das Tool JTL-Wawi-Datenverwaltung kann vollständig auf die auf CentOS laufende SQL-Datenbank zugreifen und diese fehlerfrei behandeln. Deshalb konzentriere ich mich auf den Anmeldevorgang des Programms JTL-Wawi.

Die Suche mit den Suchbegriffen:
jtl wawi SQLState: 01000
jtl wawi SQL Server Error: 772
jtl wawi SQLState: 08001
jtl wawi SQL Server Error: 18

führt zu zahlreichen Suchergebnissen, die allesamt ebenfalls um die zuvor geschilderte Vermutung des ODBC- und Verschlüsselungsproblems deuten.

Läßt man vorerst beiseite, daß JTL aus was für auch Gründen nur Windows-Installationen, könnte JTL aus den zahlreichen bereits gelösten Tickets ein Licht am Ende des Tunnels für mein Problem werfen. Schließlich gibt es Benutzer, die diese gleiche Problematik hatten; diese teils gelöst haben oder auch nicht und die Lösungen von JTL nur deshalb nicht verwertet werden, weil man sich ausschließlich auf Windows festgelegt hat.

Das ist aus meiner Sicht des Admins und Unternehmers zu kurzsichtig. Am Ende ist eine SQL-Datenbank ein Dienst und mir ist es gleich, ob diese unter Windows oder Linux läuft. Da selbst Microsoft nach vielen, vielen Jahren zu der Erkenntnis gekommen ist, daß man Linux nicht fürchten sondern lieben kann, könnte JTL den Standpunkt vielleicht überdenken. Ich schreibe nur vielleicht

Weshalb ist es andererseits betrachtet ist es eine echte Chance, wenn JTL immer in Stein meißeln würde, Linux niemals zu unterstützen? Linux ist in den meisten Fällen kostenlos, schlank und läßt sich binnen Minuten schnell installieren. Wenn ich allein diese drei Vorteile betrachtet, komme ich als Linux-Neuling ins Schmunzeln. Ich habe gestern CentOS und MS SQL in nur 1 Stunde installiert (Downloadzeiten und das Lesen der Installationen inbegriffen). Wow, ich bin seit 30 Jahren nur mit Windows unterwegs gewesen und brauche für die Installation eines Servers 2019 mit SQL Server immer noch deutlich länger. Zugegeben, die Verbindung zwischen JTL Wawi und SQL klappt dann, ohne daß ich bis 5 Uhr wach sein und am nächsten Morgen lange Texte schreiben muß. Aber hört deshalb für mich damit der Lernprozess auf? Wenn ich nur mit Sicherheit wüßte, daß JTL niemals das Linux-Terrain betreten wird, würde ich alle Linux-Begeisterte dazu ermutigen, sich zusammenzuschließen und gewinnorientiert eine Windows-Linux-Lösung zusammenzustellen inkl. des dafür eigenen Supportbereichs. Der dann ab und an antworten dürfte: "Bei Windows basierten Probleme wenden Sie sich bitte an den JTL-Support, das können sie viel besser als wir."

Ich habe mich immer wieder für Linux interessiert und bin am gleichen Punkt gescheitert. Wenn ich heute darüber nachdenke, kommt mir der Gedanke, daß ich aufgab, nur weil ich nicht weiterkam. Fand ich jemand, der zumindest wußte, daß Linux keine Modedroge war, stellte man mir (inkl. meines IT-Lehreres im Jahr 2017) die Gegenfrage, "was willst Du mit Linux und wer benutzt es schon...“.

Ich bin erleichtert, daß ich diesmal kein Ticket eröffnen muß und hoffe, daß mein Beitrag dazu führen wird, daß sich Externe dieser Problematik annehmen, denn wenn eine JTL-Wawi auf einen Linux-basierten SQL-Server zugreifen kann - und dies ist sicher nicht Lichtjahre entfernt, wie man dem Werbeslogan von JTL „Wir unterstützen MS SQL Server aktuell ausschließlich unter Windows.“ fälschlicherweise entnehmen könnte, dann hoffe ich, bald fit genug in Linux zu sein nach dem Motto „Sag niemals nie“.

In diesem Sinne freue ich mich, wenn sich diejenigen zu Wort melden, die ein Stück weiter sind als ich. Ich verspreche hoch und heilig, das gewonnene Wissen nicht mit JTL zu teilen, um schlafende Hunde nicht zu wecken. Nicht auszudenken, was passieren würde, wenn JTL künftig auch noch Linux unterstützen würde...