Inaktiv Update auf 1.4.30.2 - Fehlermeldung Verletzung der PRIMARY KEY-Einschränkung "PK_tPlattform"

[SebiW]

Auf unserem Testsystem erhalte ich bei einem unserer Mandanten folgende Fehlermeldung beim Upgrade auf die 1.4.30.2:

Unbehandelte Ausnahme #959190594F6282F vom Typ System.Exception in
System.Exception: 09:46:36 Fehler in der Version 1.4.30.2 beim Befehl:
==============================================
SET IDENTITY_INSERT dbo.tPlattform ON;

INSERT INTO dbo.tPlattform(nPlattform, cName, cID, nInet, nTyp)
VALUES(150, 'JTL-POS', 'JTL-POS', 0, 10)

SET IDENTITY_INSERT dbo.tPlattform OFF;
==============================================
Message: Verletzung der PRIMARY KEY-Einschränkung "PK_tPlattform". Ein doppelter Schlüssel kann in das dbo.tPlattform-Objekt nicht eingefügt werden. Der doppelte Schlüsselwert ist (150).
LineNumber: 3
Procedure:


2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tNotiz
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tgutschrift
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tEingangskanalEmail
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tpk
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tAttribut
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tNachrichtTyp
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tAntwortkanal
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tAttributSprache
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.ebay_geaenderte_laufende_angebote
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tUserLayout
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tNachricht
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tEingangskanalEmailLabel
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tVersandInfo
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Ticketsystem.tGeleseneEmail
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tOauthConfig
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tLagerbestandBackup
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tPlattform
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Amazon.tRetourPosGutschriftMapping
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tAdresse
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.dbo.tUpdateLog
2019-06-25T09:46:36 DEBUG - [TableCache] Invalidate: Mandant_2.Kunde.tHistorie
2019-06-25T09:46:36 DEBUG - SELECT * FROM [tOptions]
2019-06-25T09:46:36 DEBUG - Dauer: 2 ms, 117 Zeilen
2019-06-25T09:57:09 DEBUG - SELECT (CASE WHEN SERVERPROPERTY('MACHINENAME') = HOST_NAME() THEN 'local' ELSE 'remote' END) AS instance
2019-06-25T09:57:09 DEBUG - Dauer: 0ms, Result: local

 

[Michael Spaltmann]

Hi,
von welcher Version updatest Du den Mandanten? Benutzt Du das Ticketsystem? Von einer Version vor der 1.4.30 muss man das Ticketsystem einmal komplett leeren bevor man einen Mandanten updaten kann. Das SQL dass dafür auf dem Mandanten abgesetzt werden muss lautet

delete from Ticketsystem.tEingangskanalEmail
delete from Ticketsystem.tAusgangskanalEmail
delete from dbo.tCryptoSlot where nSlotId = 2
delete from dbo.tCryptoVault where nSlotId = 2

Dann sind auch alle Daten aus dem Ticketsystem entfernt.

 

[SebiW]

Hi Michael, ich habe es einmal von der 1.4.20 versucht und einmal von unserer aktuell eingesetzten 1.4.26.1.
Das Ticketsystem haben wir bisher nicht verwendet, auch auf der Test DB nicht. Das sind mehrere Einzelmandanten und da steht ja allein schon dieses Ticket davor: https://issues.jtl-software.de/issues/WAWI-36786
Unabhängig davon versuche ich damit mal mein Glück.

 

[Michael Spaltmann]

Hi,

ne das wird Dir dann nicht helfen. In deinem Log sieht man dass beim Update versucht wird in tPlattform für nPlattform die 150 für die POS angelegt werden soll. Die ist aber schon belegt. Benutzt Ihr eine andere Kasse oder Unicorn oder sowas in der Art? So lange Ihr in tPlattform schon für nPlattform = 150 was drin habt wird das Update knallen. Aber wenn Ihr dem Übeltäter jetzt einfach ne andere ID gebt wird das das Ganze eher verschlimmbessern. Falls das ein 3. Anbieter ist müsstet Ihr den Fragen wie man das Ganze Modul auf ne andere ID strickt.

 

[SebiW]

Hallo Michael,

danke nochmal für die Antwort. Ist tatsächlich Victor von @Visitmedia | Marc der hier blockiert. Ich habe gerade mal ein Supportticket an Visitmedia eröffnet, mal sehen ob es dafür schon eine Lösung gibt.
Ansonsten wäre das natürlich unschön.

Grüße, SebiW

 

[Michael Spaltmann]

Hi,

ich hab intern bei uns auch nochmal nachgehakt und unsere Entwickler sind da auch dran.

Grüße Michael

 

[Marc Völker]

Hallo,

ja Ticket ist erstellt. Ich meine wir können gerne die ID ändern, Problem ist nur, ich muss halt dann auch alle bestellungen abändern. Fände ich sehr unsauber.
Wir hatten uns damals halt extra den bereich zwischen 140-200 ausgesucht, da dort JTL keine eigenen Plattformen hatte 😉

Technisch brauche ich für mich nur die cID die stimmen muss. Um den für mich zuzuordnen. Daher für die zukunft kein Problem, lieber wäre es mir ja wenn die nPlattform generell kein Problem darstellt.

Vor allem schwierig, wenn ich das richtig sehen, nutzen unsere Produktion aktuell schon sehr viele. Sprich viele Instanzen wo wir das Updaten müssten 🙁

 

[SebiW]

Vielleicht wäre es an dieser Stelle einfach mal sinnvoll auch von JTL Seite aus einen ID BEreich zu definieren der für Partnertools genutzt werden kann.
Darf ja gerne 500+ sein, ist halt nur doof wenn am Ende ganze Tools nicht mehr laufen weil spontan alle KAssen eigene IDs kriegen 😉

 

[Marc Völker]

Das Thema ist glaub ich schwierig, generell ist die Id auto generiert, das sollte auch kein Problem darstellen, weil man sich ja an der cID orinieren kann, und nicht an der kPlattform.
Problem ist nur, es gibt noch einige stellen im Bereich Auftrag 2.0 wo das ganze dann umgebaut werden muss, gerade weil dort noch ein kleinerer Zahlenbereich von 0-256 nutzbar ist. Sprich hier würde es dann bei einer ID die größer ist Kollidieren. Halt damit auch keine Lösung.

@Michael Spaltmann
gerne können wir ja hier eine gemeinsame Lösung mit eurer Dev suchen, um das zu regeln.