Neu amazon / Ein Fehler ist aufgetreten, bitte beim JTL-Support melden

[Merlin84]

@John

Seitdem HG an Bord ist, hat sich doch einiges geändert. Und ich glaube, wir sind uns einig, dass hier auch finanzielle Interessen mit dem Lizenzsystem im Spiel sind.

Wir sind mit der Version 1.5.55.8 nach wie vor sehr zufrieden und würden diese auch weiterhin einsetzen.

Ich vermute nur, dass, sobald wir nun den Hotfix nehmen, in ein paar Monaten wundersamerweise dann etwas nicht mehr funktioniert und dass man einen dann zwingt, auf die 1.9-Version zu wechseln.

Wir sind mit der alten Version glücklich, es läuft alles, wie es sein muss.

 

[Volldurcheinander]

@John

Seitdem HG an Bord ist, hat sich doch einiges geändert. Und ich glaube, wir sind uns einig, dass hier auch finanzielle Interessen mit dem Lizenzsystem im Spiel sind.

Wir sind mit der Version 1.5.55.8 nach wie vor sehr zufrieden und würden diese auch weiterhin einsetzen.

Ich vermute nur, dass, sobald wir nun den Hotfix nehmen, in ein paar Monaten wundersamerweise dann etwas nicht mehr funktioniert und dass man einen dann zwingt, auf die 1.9-Version zu wechseln.

Wir sind mit der alten Version glücklich, es läuft alles, wie es sein muss.

Naja, ob das nun "zwanghaft" so wäre.
Wenn ich den Fall rekonstruiere, hat JTL nicht Schuld daran, sondern Amazon.
dort wurde in der Schnittstelle ein Integrer hinzugefügt, was wohl zu einer Stelle führt, die der Import nicht annehmen kann.
und somit: zum "Gau"

Die Frage mit dem "hotfix" ist nun eine interessante einer.
Denn:
wenn man nun die 1.5 verändern wöllte (also typischerweise) müßte man das gesamte SourceProjekt noch offen haben
bzw. zugängig. da die Import schnittstelle jedoch seitens JTL (vermute ich) nicht modular ist (sonst wäre sie updatebar in jeder version),
was in Bezug auf datenbankänderungen sinn ergibt (da z.B. die 1.6 neue Felder hinzufügt, Grund des langen Updates),

... ist das sub optimal. Also hier kann man für den Support - ne Lanze brechen -
denn es war sichelrich nicht von JTL gewünscht, dass Amazon mal eben die schnittstelle (sicher wieder ohne Ankündigung)
von heute auf morgen umstrickt.

... so macht an sich auch der Aufstieg zu höheren versionen einen sinn.
Normal arbeitest du nur in einem projekt, rückläufige sind dann ein Mehraufwand, alles Gut so weit.

... allerdings:
das Liztenzsystem , ist nicht gut.
dort sind wir absolut einer Meinung. Keine Frage.

 

[elevennerds.de]

dort wurde in der Schnittstelle ein Integrer hinzugefügt

Hast Du Dir das mal angeschaut? Da ist ein INT übergelaufen, eine Zahl, die kontinuierlich hochzählt, d.h. JTL hat da jahrelang raufgeschaut und das Problem kommen sehen. Dass das Ding in der DB als 32bit Zahl abgespeichert wurde, war auch nicht die Schuld von Amazon, sondern eine bewusste Entscheidung von JTL.

 

[John]

Hast Du Dir das mal angeschaut? Da ist ein INT übergelaufen, eine Zahl, die kontinuierlich hochzählt, d.h. JTL hat da jahrelang raufgeschaut und das Problem kommen sehen. Dass das Ding in der DB als 32bit Zahl abgespeichert wurde, war auch nicht die Schuld von Amazon, sondern eine bewusste Entscheidung von JTL.

Das muß keine schuldhafte Entscheidung von JTL gewesen sein. Vielleicht war es in der Doku der Amazon API die letzten 20 Jahre als INT deklariert. Dann hat Amazon irgendwann gemerkt, dass Ihnen der Raum zu knapp wird und sie haben auf BIGINT erweitert.
JTL hat diese Änderung ja auch in den aktuellen Versionen mit gemacht.

Aber das Problem zeigt exemplarisch, wieso man nicht an einer alten Version festhalten kann, auch wenn man sich das vielleicht aus Gründen der Routine oder Kosten wünscht:
Die Welt dreht sich weiter, Dinge ändern sicht und Software, die mit der Welt interagiert, muss angepasst werden.

Das erste JTL/Amazon Desaster mit Überlauf vor einer Weile, die Wiederholung jetzt, UPS oAuth, TLS 1.3 vs altes Windows, gmail Auth...nur ein paar Beispiele der letzten Zeit.

Ich habe auch hinter dem neuen Lizenzsystem zuerst die große Investor Verschwörung gewittert, sehe das aber inzwischen differenziert.
Das alte Linzenzsystem stammte aus der Urzeit der Wawi und das man dort mal etwas überarbeitet, ist verständlich.

Ob und in welchem Umfang der neue JTL Eigentümer mehr Geld von uns haben will, wird sich zeigen.
Dafür braucht man im Übrigen kein aufwändiges Lizenzsystem.
Dafür reicht auch eine Entscheidung wie: Wir wollen ab sofort 1% des Umsatzes, den Ihr über die Wawi abwickelt. Dafür sind alle Funktionen und Marktplätze inklusive. Andere Systeme gehen ja in diese Richtung...

wenn man nun die 1.5 verändern wöllte (also typischerweise) müßte man das gesamte SourceProjekt noch offen haben
bzw. zugängig. da die Import schnittstelle jedoch seitens JTL (vermute ich) nicht modular ist

Das ist ja wohl mit GIT die kleinste Übung und Du bist wieder zurück beim Sourcecode Stand 1.5
Und natürlich ist das teilweise modular, sonst hätten Sie nicht die gepatchte DLL für die 1.5 erzeugen können.

 

[AMP-Agentur]

@John

Seitdem HG an Bord ist, hat sich doch einiges geändert. Und ich glaube, wir sind uns einig, dass hier auch finanzielle Interessen mit dem Lizenzsystem im Spiel sind.

Wir sind mit der Version 1.5.55.8 nach wie vor sehr zufrieden und würden diese auch weiterhin einsetzen.

Ich vermute nur, dass, sobald wir nun den Hotfix nehmen, in ein paar Monaten wundersamerweise dann etwas nicht mehr funktioniert und dass man einen dann zwingt, auf die 1.9-Version zu wechseln.

Wir sind mit der alten Version glücklich, es läuft alles, wie es sein muss.

Die 1.5 wird ohnehin nicht mehr unterstützt. Irgendwann wird auch das Finanzamt auf ein GoBD konformes System drängen. Rechnungen und Rechnungskorrekturen werden dort festgeschrieben und sind nach der Erstellung nicht mehr änderbar. Das heißt, wisst du Rechnungen ändern, musst du diese stornieren und neu ausstellen. Dafür gibt es dann auch Storno-Belege. Das war auch eine große Neuheit in der 1.6.

Viele Neuheiten und Änderungen werden auch von der EU bzw. dem Gesetzgeber verlangt. So auch viele Änderungen und Prüfungen, die Amazon so durchführt.

Wenn du die 1.5.55.8 nutzt, wird dir eh nicht weiter überbleiben, als auf die 1.8.12.2 zu gehen.
Der große Schritt mit den großen Änderungen ist der auf die 1.6. Alles, was danach kommt, sind normale Updates, wo keine großen Anpassungen hat.

 

[Volldurcheinander]

Das muß keine schuldhafte Entscheidung von JTL gewesen sein. Vielleicht war es in der Doku der Amazon API die letzten 20 Jahre als INT deklariert. Dann hat Amazon irgendwann gemerkt, dass Ihnen der Raum zu knapp wird und sie haben auf BIGINT erweitert.
JTL hat diese Änderung ja auch in den aktuellen Versionen mit gemacht.


Das ist ja wohl mit GIT die kleinste Übung und Du bist wieder zurück beim Sourcecode Stand 1.5
Und natürlich ist das teilweise modular, sonst hätten Sie nicht die gepatchte DLL für die 1.5 erzeugen können.

sieh schrieb ich schon. Ich schiebe die Schuld hierfür nicht nach JTL. Ich denke die hat es genau so in voller Dusche erwischt, wie die Nutzer.
Das ist es nicht.

zu Git
Ringt mir immer ein lachen ab, aber ok

 

[elevennerds.de]

Das muß keine schuldhafte Entscheidung von JTL gewesen sein.
JTL hat diese Änderung ja auch in den aktuellen Versionen mit gemacht.

Hast Du das selber mal gelesen?

 

[Volldurcheinander]

Hast Du Dir das mal angeschaut? Da ist ein INT übergelaufen, eine Zahl, die kontinuierlich hochzählt, d.h. JTL hat da jahrelang raufgeschaut und das Problem kommen sehen. Dass das Ding in der DB als 32bit Zahl abgespeichert wurde, war auch nicht die Schuld von Amazon, sondern eine bewusste Entscheidung von JTL.

Übergelaufen ?

das wäre mir neu.
Lt. JTL wurde ein weiterer Wert hinzugefügt ?

 

[Volldurcheinander]

Die 1.5 wird ohnehin nicht mehr unterstützt. Irgendwann wird auch das Finanzamt auf ein GoBD konformes System drängen. Rechnungen und Rechnungskorrekturen werden dort festgeschrieben und sind nach der Erstellung nicht mehr änderbar. Das heißt, wisst du Rechnungen ändern, musst du diese stornieren und neu ausstellen. Dafür gibt es dann auch Storno-Belege. Das war auch eine große Neuheit in der 1.6.

Viele Neuheiten und Änderungen werden auch von der EU bzw. dem Gesetzgeber verlangt. So auch viele Änderungen und Prüfungen, die Amazon so durchführt.

Das kommt eben darauf an, wofür man JTL benutzt.
Wir z.B. erstellen gar keine Rechnungen in JTL.
Ist alles eben immer eine Frage - wie, wofür, was macht man damit usw. usw.

unsere verwendung entspricht nicht der typischen einer Warenwirtschaft, eher nur einer Verwaltung.
Darum haben wir auch exact (ganz genau) ... 0,00 Artikel im JTL angelegt... wäre sinnfrei. Würde uns nur unmassen Zeit und Aufwand für nichts kosten.

 

[forumjtlolshopag]

Naja, ob das nun "zwanghaft" so wäre.
Wenn ich den Fall rekonstruiere, hat JTL nicht Schuld daran, sondern Amazon.
dort wurde in der Schnittstelle ein Integrer hinzugefügt, was wohl zu einer Stelle führt, die der Import nicht annehmen kann.
und somit: zum "Gau"

Nein, es kam zu einem Überlauf einer Internen Id. Es wurde eine höhere Zahl geliefert als wie in der Datenbank bei der Tabelle für den Amazon Bestell Status gespeichert werden kann. Das gleiche Problem, was Ende 2023 bei der "Amazonbestellungen importieren" passiert ist. Der Fix von Ende 2023 war einfach unvollständig. Man hat nicht bedacht, das beim Amazon Bestellstatus das gleiche auftreten würde. Man hätte Ende 2023 eigtl. alle Amazon betroffenen Tabellen in JTL auf jeweils BIGINT nehmen müssen, dann wäre das Thema garnicht erst aufgetreten. Sozusagen hätte eventuell auch JTL generell bedenken müssen, ob die Datentypen der Tabellen von externen Diensten ausreichend groß genug sind. Könnte mir vorstellen, dass da sogar Informationen dazu in der Amazon API Dokumentation existieren.

 

[elevennerds.de]

Ich kann mir auch nur schwer vorstellen, dass dieses Problem bei JTL niemand kommen sehen hat. Zumal in JTL-Versionen ab 1.6 das Problem ja bereits behoben war. JTL war sich dessen also bewusst und hat uns diese kleine Zeitbombe in JTL 1.5 drin gelassen...

 

[Nina L.]

Hallo @Volldurcheinander , wir weisen dich hiermit darauf hin, unsere Forenregeln zu beachten. Bitte halte die Kommunikation konstruktiv und sachlich.

 

[Merino_81]

Das ist dann kein Hotfix das ist ein Witz. Wer will denn direkt auf 1.9? Damit dann später gar nichts mehr funktioniert. Alleine von den ganzen Problemen mit den Workflows und Formularen die man hier so lesen darf.

Also ich bin von der 1.5 auf die 1.9 mithilfe von Ecomdata. Dies hat auch nur eine Stunde gedauert (musste aber EComData 90€ zahlen). Dann meldest du dich einfach in der WaWi nochmal bei JTL an und es läuft. So war es bei mir jedenfalls, da ich mit dem Hotfix nicht klargekommen bin und ich das Update so oder so machen müsste. Es gibt Veränderungen, aber ich als Neuling kann dir sagen, dass man sich zurecht findet. Wichtig ist dass du so ca 3-4 GB speicher hast. Also falls dein Hosting bei EcomData oder bei der JTL ist, melde dich bei Ihnen, dass Sie dir das Update machen. Ich hatte bereits ein Ticket bei der JTL, welches auch noch offen ist, falls ich doch noch unkalrheiten haben sollte, dass ich mich melden kann. Der Support reagiert auch sehr schnell und ich habe nur ein basic Abo.

 

[neuling-help]

Das kommt eben darauf an, wofür man JTL benutzt.
Wir z.B. erstellen gar keine Rechnungen in JTL.
Ist alles eben immer eine Frage - wie, wofür, was macht man damit usw. usw.

unsere verwendung entspricht nicht der typischen einer Warenwirtschaft, eher nur einer Verwaltung.
Darum haben wir auch exact (ganz genau) ... 0,00 Artikel im JTL angelegt... wäre sinnfrei. Würde uns nur unmassen Zeit und Aufwand für nichts kosten.

wenn du 0,00 Artikel in JTL hast, wieso benötigst du dann die Schnittstelle zu Amazon? . Verstehe aktuell nicht, warum alle ein Problem mit dem Hotfix haben. Einfach rein das Ding, weiter arbeiten und die Zeit sinnvoll in das Unternehmen stecken = Umsatz steigern .

 

[christian-wenzl]

Hallo zusammen,

ja, das Update von älteren Versionen sollte regelmäßig gemacht werden. Mir ist aber auch klar, dass es gerne geschoben wird. Das hat scheinbar auch die Diskussion recht stark entfacht.

Wie mehrfach in diesem Thema gelesen gibt es auch Probleme bei der Übermittlung der Sendungsdaten an Amazon.

Da bei uns der Fall schon öfters aufgetreten ist, vielleicht eine kleine Hilfestellung für alle Betroffenen, die schnell die Sendungsdaten hochladen möchten.
https://www.christian-wenzl.de/trackingdaten-erneut-mit-jtl-an-amazon-uebermitteln/

Viele Grüße, Christian

 

[Volldurcheinander]

Hallo zusammen,

ja, das Update von älteren Versionen sollte regelmäßig gemacht werden. Mir ist aber auch klar, dass es gerne geschoben wird. Das hat scheinbar auch die Diskussion recht stark entfacht.

Wie mehrfach in diesem Thema gelesen gibt es auch Probleme bei der Übermittlung der Sendungsdaten an Amazon.

Da bei uns der Fall schon öfters aufgetreten ist, vielleicht eine kleine Hilfestellung für alle Betroffenen, die schnell die Sendungsdaten hochladen möchten.
https://www.christian-wenzl.de/trackingdaten-erneut-mit-jtl-an-amazon-uebermitteln/

Viele Grüße, Christian

Hallo christian.
für den Abgleich nach oben, haben wir bereits eine Lösung, die ohne JTL Eazy Auction Server funktioniert, und das hervorragend.

ja, das Update von älteren Versionen sollte regelmäßig gemacht werden. Mir ist aber auch klar, dass es gerne geschoben wird. Das hat scheinbar auch die Diskussion recht stark entfacht.

ja, auch auf die Gefahr hin es erneut zu wiederholen:
Updates haben ihr Für und Wieder, hier jedoch sind sie teilweise brachial.
Für den Tante Emma Laden, haben viele neue Dinge einfach keinen Sinn. Ege, ein Ebay Verkäufer, der 3 Produkt Sortimente verkauft, trampelt nicht
mit Packwagen, 50 mitarbeitern und Pickliste los, der greift seine 3 Gymmiks ausm Regal.
Dennoch gibt es vieles was er nutzt.

Es ist die Community, die JTL groß machte.
Nun ist JTL etwas größer, und will größer werden, interessanter für "big Business" so zu sagen- Dabei wird aber das small Business beerdigt.
Eisenhart: "Zieh mit oder stirb".

... dort liegt das Problem.
Mit einem Update nun X funktionen "hineinfressen" die Du nicht brauchst, ist schlicht: irrsinn. Unfug. schwachsinn.
Sind unnötiger Ballast.


Viele der internen Umstellungen, erschweren aber die Arbeit.
z.B . bei uns kommen keine Ausdrucke mehr in Folge. Was dann zum Ergebnis hat, das wir ewig herumsuchen und sortieren mussten,
bis wir überhaupt mal wieder eine reinfolge in den Lieferscheinen hatten. == Proiblem 1, Dank Update. Wollte keiner, mussten wir.
keine Wahl...

vieles weiteres kommt halt hinzu. Abläufe werden erschwert, Zeug eingebaut was wir nicht benötigen.
Hinzu funktionieren Dinge nich tmehr. Z.b: haben wir Ringeltanz hinter r uns, das Rechnungen damals nicht gesendet wurden, nur jede 3.
warum ? update.
..-.
Formulare gingen nicht mehr, warum ? update. Kostenpunkt 1800 Euro, muss erst mal verdient werden.

usw. usw. usw. die Liste aus 18 Jahren Erfahrung *ist ein wenig lang* die geht noch weiter..
wenn man das nun bedenkt:

Was willst du ? arbeiten.
Was tut das Update ? Dich davon abhalten, und die Arbeit erschweren.
Willst du das Update ?

öhm. nein.

Macht irgendwo sinn, oder?
nun kann man ewig diskutieren, in andere Bereiche ja doch kann man. Aber das ändert essentiell nichts an der Thematik,
das du bis gerade arbeiten konntest, danach updatest, und es geht nichts mehr.
Du bist dann essentiell im Stop. Einer schrieb hier: "Ich setz die Firma in Amazon jetzt auf Urlaub" - ja - so endet das.
Das ist das PRoblem.

Darum will keiner updaten.
Weil es einfach oftmals extreem viele Probleme nach sich zieht. das hat weder etwas mit "Offenheit für Updates"
noch mit "schieben" als solches zu tun.

reiner Selbsterhaltungstrieb.

 

[Volldurcheinander]

wenn du 0,00 Artikel in JTL hast, wieso benötigst du dann die Schnittstelle zu Amazon? . Verstehe aktuell nicht, warum alle ein Problem mit dem Hotfix haben. Einfach rein das Ding, weiter arbeiten und die Zeit sinnvoll in das Unternehmen stecken = Umsatz steigern .

Naja, der ursprüngliche Punkt ist hier speziell, da SQL Server 2012.
Aber das ist mittlerweile unerheblich geworden.

Die investierte Zeit ist eine gute einer.
Sie gibt Denkanstöße, Änderungen und damit auch: Verbesserungen.
Der "Hotfix" ist halt uninteressant durch die Update Einschränkung.

Ich würde gern auf die 1.6 gehen, und nicht direkt mit der Rakete nach "Bughausen" abheben.
Denn ich erwarte schreckliches bei der 1.8 oder höher. Außerdem weiß niemand, ob eine SQL 2012
damit funktioniert.

Daher ist der Gedanke folgender:
Die Umrechnung auf die 1.6 kostet so ungefähr 200 Jahrmilliarden Jahre. Also: Starten während die Dinosaurier noch die
Welt beherrschten, Update Fertig im Jahr 3500 nach Christus. (Das ist Ironie, aber es verdeutlicht die problemstellung)
Aus der SQL 2012, lässt sich nun ein Beckup extrahieren, unter der Version 1.6 Die Erkenntnis das SQL 2012 und 1.6
funktionieren, ist vorhanden. Das habe ich bereits in der Vergangenheit ausprobiert, das geht.

Somit hätte ich diese exorbitante "Umrechnerrei" nur 1x ,und dann ein Beckup von dem aus ich experimentieren,
ggf. sogar wechseln kann, ohne das ich ewig dauernt bei jedem gescheitertem Versuch für ??? Stunden
den Umrechnugnsprozess abwarten muss.

Die nun folgende Vorgehensweise - die mir persönlich lieb wäre ist:
1. - Update 1.55 auf 1.6.
2. - nach Fehlern und Bugs suchen, diese beheben. Die Umrechenzeit auf die 1.6 hinter sich bringen (Essentiell)
3. - ab diesem Punkt: Volles Beckup.
4. - und ERST DANACH den Versuch machen, auf die 1.7 / 1.8 zu steigen.

Was ich vermeiden möchte:
Wenn ich 1x umrechne und versuche z.B. die 1.8, und scheitere an der SQL 2012, werfe ich sämtliche Umrechenzeit in den Wald.
Das hat sich dann. Da ist: feierabend. Ende. Finito. Aus die Maus.

... darum möchte ich zuerst mal:
ein Update, das - sichern - und dann hoch auf die 1.8 oder höher, und mich da umschaun.

Allerdings sage ich auch ganz klar:
das neue Lizenzmodell, und wir, werden keine Freunde.
ggf. hat sich das damit sowieso erledigt, da wir mittlerweile über eine Alternative diskutieren.
Eine +100% Preisverteurung (ggf. mit Stage version x2,5 etc)
.. .ist zu happig. geht nicht bei unseren Magen, wir versenden dann nur noch um JTL zu bezahlen,
das macht keinen Sinn.

 

[Underbär]

Der Import- und Export-Ablauf von Bestelldaten beim Amazon-Abgleich ist in den 1.5er-Versionen von JTL Wawi derzeit gestört.

Daher wird euch aktuell beim Abgleich eine Fehlermeldung angezeigt, mit der Bitte sich an den JTL-Support zu wenden. Im Fehlerlog finden Sie außerdem folgende Meldung: „System.OverflowException: Der Wert für einen Int32 war zu groß oder zu klein.“

Das müsst Ihr jetzt tun
Bitte führen Sie schnellstmöglich ein Update auf unsere aktuelle JTL-Wawi-Version 1.9.4.5 durch. Die neueste Version von JTL-Wawi finden Sie auf unserer Website: https://www.jtl-software.de/jtl-wawi-download

Solltet Ihr derzeit kein Update auf unsere aktuelle JTL-Wawi-Version vornehmen können, stellen wir hier eine ZIP-Datei mit SQL- und DLL-Daten zur Verfügung. Falls Sie Unterstützung bei der Implementierung dieser Dateien benötigen, steht Ihnen unser Support gerne zur Verfügung.

WICHTIG: Bitte beachtet, dass der Support für die Versionen 1.5 von JTL-Wawi, wie bereits in einem Info-Mailing angekündigt, zum 31.07.2024 ausläuft. Wir weisen darauf hin, dass bei Nutzung des hier angebotenen Hotfixes via DLL/SQL ein Update auf aktuell veröffentlichte Versionen technisch nicht mehr möglich ist. Ein Update wird erst wieder mit allen kommenden Versionen (ab 1.9.4.6) möglich sein. Die hier genannte Lösung ist aufgrund des beschriebenen Supportende somit eine Übergangslösung.

In der angehängten ZIP-Datei befinden sich eine SQL-Datei und eine DLL-Datei. Bitte fertigt, wie gewohnt, vor dem Absetzen des SQL-Query nach Abschalten des Workers und Schließen der Wawi ein Backup der Datenbank an.
Die DLL-Datei ersetzt ihr im Stammverzeichnis der Wawi gegen die dort bestehende Datei.

Bei technischen Rückfragen erstellt gerne bis zum Abkündigungsdatum ein Support-Ticket im JTL-Kundencenter mit der entsprechenden Produktauswahl.

muss die dll auf allen clients getauscht werden oder nur auf dem server?

 

[forumjtlolshopag]

muss die dll auf allen clients getauscht werden oder nur auf dem server?

Wir haben es aktuell nur da gemacht, wo der Worker arbeitet. Sieht bisher gut aus. Keine Ahnung welche Auswirkung es noch haben könnte...

 

[SebiW]

@Volldurcheinander Die 1.6 ist aber schlicht keine gute Version. Mit der wirst Du garantiert nicht glücklich. Die 1.7 ist deutlich besser, die 1.8 ebenfalls. Der 2012er SQL ist tot. Die 1.5 ist tot. Die 1.6 ist tot. Die 1.7 ist tot.
Dein ganzes Vorgehen macht einfach überhaupt keinen Sinn. Als jemand, der die 1.6 von Beta an so lange getestet hat bis am Ende der reale Umstieg 1.5 direkt auf die 1.7. lief weil KEINE 1.6er zufriedenstellend funktioniert hat: Lass es.

Hol Dir nenn gebrauchten SQL 2017er oder 2019er mit entsprechend CALs, zieh ne 1.8er hoch und hab wieder n paar Jahre Ruhe. Du machst Dir mit Deinem Ansatz nur verdammt viel mehr Arbeit als nötig. Und Arbeit ist Zeit ist Geld.