MSSQL Express als Kommunikationsmedium

[mihe7]

Hallo miteinander,

zwar betrifft das Java nur am Rande (am äußersten Rande ) aber ich grüble momentan an einem kleinen Problem, für das ich mangels Erfahrungen mit dem SQL-Server keine wirkliche Idee habe, die mir gefällt. Folgende Situation: ein Bekannter (kleiner Handwerksbetrieb mit Ladengeschäft) hat eine WaWi im Einsatz, klassische Client/Server-Architektur mit SQL Server Express.

Es geht nun darum, Daten aus der WaWi heraus auf Knopfdruck an eine auf dem gleichen Server laufende Java-Anwendung zu senden und das Ergebnis in der WaWi anzuzeigen bzw. in diese zu übernehmen. Ich will da nicht näher auf die Umstände eingehen, jedenfalls liegen so abgefahrene Dinge wie Kommunikation mit Drittanwendungen nicht im Kompetenzbereich der "Berater". Angeblich können sie aber beliebige SQL-Anfragen über die Makrosprache der WaWi (auf die man als Kunde keinen Zugriff bekommt) an den Server stellen. Mit dem SQL-Server selbst kennen sie sich leider auch nicht wirklich aus.

Würde dahinter nun eine Oracle DB laufen, hätte ich eine einfache Lösung: dbms_pipe. Eine Procedure schreibt in eine Pipe, die Java-Anwendung liest daraus, antwortet, fertig. Daher habe ich mal in die Richtung recherchiert, für den SQL-Server hätte ich aktuell folgende Optionen im Angebot:

1. Service Broker - aber, soweit ich das bei MS gesehen habe, kann die Express nur als Client verwendet werden
2. REST-Request in einer Stored Procedure. Ungern, weil das etwas ist, was dann alle Jahre mal daherkommt und man sich dann jedesmal einarbeiten muss. Außerdem weiß ich nicht, ob das in Express funktioniert
3. Befehl auf dem Server aus SQL-Server heraus aufrufen (xp_cmdshell) - äußerst unschön

Am schönsten fände ich eine abgespeckte Variante von 1 (wie dbms_pipe). Ich brauche keine großartigen Queues, kein Message Routing, einfache Kommunikation über den SQL-Server würde schon reichen. Gibts da noch was anderes/einfacheres mit MSSQL, das ohne Polling funktioniert? Ansonsten habe ich noch eine Idee, vorausgesetzt 2. funktioniert in Express.

Ach so, noch was: kann man von Express einfach auf Standard upgraden oder ist das ein größerer Akt? Das wäre nämlich evtl. auch noch eine Option.

 

[yfons123]

kann man von Express einfach auf Standard upgraden oder ist das ein größerer Akt?

man kann relativ einfach von unten nach oben upgraden aber downgraden geht nicht

du kannst dann halt nicht mehr auf express zurück außer du installierst das ganze neu.

aber anstatt da ins blinde zu gehen:
zweiten server aufsetzen mit developer edition und das ganze aufbauen,
upgraden zur evaluation edition , 180 tage frei
falls die evaluation edition abgelaufen ist dann auf die standard edition wechseln

damit zahlst du ansich am wengisten mit nur wenig risiko da ja das andere parallel noch funktioniert.
wahrscheinlich kannst du dir die developer edition sparen da du kein halbes jahr für das ding brauchst

ein upgrade funktioniert schon , nur was ist wenns nicht funktioniert was du dir so denkst ? dann kannst du nicht zurück und im schlimmsten fall ist alles kaputt.
Also lieber parallel ein KOSTENLOSES system aufbauen und wenn das fertig ist mit dem austauschen, ist auch die empfehlung von den lehrern auf meinen schulungen gewesen

Express ist der größte mist überhaupt, du hast keinen SQL Agenten und damit keine wartungsjobs oder agenten jobs oder sonst irgendwas was man täglich braucht, du darfst maximal 1 cpu haben und 10gb maximal größe der DB
und du darfst keine hoch verfügbarkeit in irgend einer art und weise betreiben.. was wahrscheinlich wurscht ist in dem fall

 

[mihe7]

Danke für die Antwort.

man kann relativ einfach von unten nach oben upgraden

Was heißt "relativ einfach"? Installer ausführen und fertig? Will da nur eine grobe Vorstellung vom Aufwand bekommen.

dann kannst du nicht zurück und im schlimmsten fall ist alles kaputt.

Sicherung?

Ne, ernsthaft: klar würde ich das vorab testen (schon aus dem Grund, damit ich sehe, wie das im Detail mit dem Broker abläuft), aber ein Versionszirkus, um ein paar Euro an Lizenzgebühren zu sparen, kommt nicht in Frage. Für die Installation auf dem Echtsystem ist eine Firma zuständig, da kostet die Arbeit wahrscheinlich mehr als das, was man sich ggf. an Lizenzgebühren spart. Ganz davon abgesehen, dass Arbeitsunterbrechungen auch kosten - in jedem Fall Nerven (und das Nervenkostüm ist da mittlerweile sowieso äußerst dünn ).

Express ist der größte mist überhaupt, du hast keinen SQL Agenten und damit keine wartungsjobs oder agenten jobs

Hervorragend, das wären zusätzliche Argumente, die man anführen kann. Vor allem: die Standard Edition ist ja jetzt auch nicht wirklich teuer, wenn ich das richtig gesehen habe.

 

[yfons123]

Upgrade to a different edition of SQL Server - SQL Server

SQL Server Setup supports edition upgrade among various editions of SQL Server. Before you begin an edition upgrade, review the resources in this article.

learn.microsoft.com

man sollte es auf einen tag hinkriegen, ist nicht so ekelhaft wie jetzt zum beispiel in oracle ein update auszuführen

was das problem ist bei einem Express zu standard upgrade ist die einrichtung des agenten da dieser ja nicht in express existiert

wir hatten das problem vor kurzem dass die einzige express die wir hatten voll war. Die express edition hat nur probleme gemacht
keinen agenten zu haben hat halt probleme wie zb

1. maintenance plans braucht man ansich nicht unbedingt da diese einfach nur spezielle agenten jobs sind, also zeitgesteuerte queries manuell ausführen über workarounds die man entweder selber schreiben muss oder man holt sich bibliotheken ... da muss man wieder durch das IT sicherheits komitee durch usw bis man das hat und dann ist man wieder davon abhängig .. unnötiger nerv faktor dafür dass mich ein paar pfenninge spart
2. du hast keinen agenten dh keine email benachrichtigungen, nichts zeit gesteuertes, keine automatischen backups durch agenten steuern ( ist schon geil ... bau dir da mal ein workaround zusammen ) .. einfach schrecklich
wir haben netbackup und das ist am einfachsten mit jobs zu managen, auch die internen backup verfahren sind am einfachsten mit agenten jobs zu managen
es war für uns immer mit extra aufwand verbunden das alles auf der drecks express nachzuholen
keine ahnung wie das überhaupt ein jahr klar gegangen ist mit der express ohne agenten, die aussage von meinem mssql chef war "wir werden nie wieder eine express version installieren und wenn es meinen job kostet"
3. keine zeitgesteuerten skripts, wenn wieder der fachbereich will "um 12e mach das da rein" dann richtest du dir den job ein der powershell startet und gut ist
4. keine sinnvolle hochverfügbarkeit, always on was das modernste ist darf man nur mit der enterprise edition machen aber mit der standard gibts andere arten um hochverfügbarkeit zu bekommen
aber ich glaube keiner hat da bock am wochenende den server bei jedem drekcs windows update zu rebooten am wochenende wenn man es mit der hochverfügbarkeit einfach unter der woche ohne unterbrechung machen kann, keine ausfallzeiten hat schon einen charme

wir haben es dann so gemacht dass wir einen neuen server erstellt haben und den anderen am laufen gehalten haben bis der neue fertig eingerichtet war
der neue hatte dann die evaluation edition mit 180 tage kostenfreier lizenz
ab dem zeitpunkt wo es fertig war musste der fachbereich nur noch den connection string ändern auf den neuen server und gut war, damit war keine unterbrechung spürbar

Sicherung

wenn du das betriebssystem halt komplett sicherst joa..

mal um die editionen zusammen zu fassen:
1. enterprise features == enterprise, evaluation, developer edition ( darf man immer machen falls kein anwender drauf arbeitet )
2. standard == reduzierte enterprise, das wichtige was fehlt ist always on
3. express == mist, kann nix

was halt noch ne option ist, man kann auf postgres umsatteln .. da zahlt man halt dann weniger weil man ja immer support will, ich glaub für postgres heißt die firma EDB die dafür support leistet https://www.enterprisedb.com/

und du darfst keine hoch verfügbarkeit in irgend einer art und weise betreiben.. was wahrscheinlich wurscht ist in dem fall

also dürfen tut man schon, aber viel spaß beim zusammen schustern..

 

[mihe7]

Danke für den Link. Das heißt: Installer durchklicken, hinterher den Agent einrichten, fertig... Das reicht mir schon mal.

wenn du das betriebssystem halt komplett sicherst joa..

Ist virtualisiert, aber mal abgesehen davon: DB sichern, Express zurückinstallieren, DB einspielen wäre jetzt der Weg, den ich sonst gegangen wäre. Gott sei Dank muss ich mich um den Schrott nicht kümmern

was halt noch ne option ist, man kann auf postgres umsatteln

Der Hersteller der WaWi sattelt da garantiert nix um.

also dürfen tut man schon, aber viel spaß beim zusammen schustern..

Ne, das braucht der garantiert nicht.

Du musst Dir das so vorstellen: es gibt einen Hersteller der WaWi, der mit dem Pöbel Kunde gar nicht kommuniziert. Vielmehr läuft das über Systemhäuser. Die wiederum haben ihre Berater, die die WaWi inkl. DB installieren und anpassen. Die WaWi und die DB bilden für die eine Einheit.

 

[yfons123]

Danke für den Link. Das heißt: Installer durchklicken, hinterher den Agent einrichten, fertig... Das reicht mir schon mal.

der agent wird normalerweise als nt service eingerichtet automatisch aber er muss halt dann eingeschalten werden und eingerichtet werden mit dem zeug was man täglich braucht wie jetzt index reorganize oder backup und solche sachen

 

[Dukel]

2. standard == reduzierte enterprise, das wichtige was fehlt ist always on

Fast. Es gibt eingeschränktes Always On. Der große Unterschied ist, dass es pro DB eine AG geben muss.

Basic availability groups for a single database - SQL Server Always On

Describes the differences between a regular and basic Always On availability group, as well as how to configure a basic availability group.

learn.microsoft.com

 

[yfons123]

Fast. Es gibt eingeschränktes Always On. Der große Unterschied ist, dass es pro DB eine AG geben muss.

Basic availability groups for a single database - SQL Server Always On

Describes the differences between a regular and basic Always On availability group, as well as how to configure a basic availability group.

learn.microsoft.com

oke wusste ich nicht

wusste nur noch dass die alten ansätze (die nicht so gut wie Always On sind) verfügbar sind
aber gut zu wissen

 

[mihe7]

Ich sag Euch was ganz anderes: habe mir per Docker mal die Express gestartet und was soll ich sagen? Der Service Broker funktioniert dort zumindest für genau den Zweck, den ich brauche. Thema erledigt