Beantwortet Update Fehler von 1.6.36 auf 1.6.38

[Flow]

Unbehandelte Ausnahme #959190594F6282F vom Typ System.Exception in
System.Exception: 05:33:32 Fehler in der Version 1.6.37.0 beim Befehl:
==============================================
UPDATE Verkauf.tAuftragPositionEckdaten
SET nIstStuecklistenvater = CASE WHEN tAuftragPosition.kAuftragStueckliste = tAuftragPosition.kAuftragPosition THEN 1 ELSE 0 END,
nIstUmlagerung = CASE WHEN tAuftrag.nType = 2 THEN 1 ELSE 0 END,
nPrio = tAuftrag.nLieferPrioritaet,
nPrioDatum = ISNULL(DATEDIFF(SECOND, DATEFROMPARTS(2021, 01, 01), tAuftrag.dErstellt), 0),
kAuftrag = tAuftrag.kAuftrag,
kArtikel = tAuftragPosition.kArtikel
FROM Verkauf.tAuftragPositionEckdaten
JOIN Verkauf.tAuftragPosition ON tAuftragPosition.kAuftragPosition = tAuftragPositionEckdaten.kAuftragPosition
JOIN Verkauf.tAuftrag ON tAuftrag.kAuftrag = tAuftragPosition.kAuftrag
==============================================
Message: Die datediff-Funktion hat zu einem Überlauf geführt. Die Anzahl von datepart-Werten, die zwei Datums-/Uhrzeitinstanzen trennen, ist zu groß. Verwenden Sie eine datediff-Funktion mit einem weniger präzisen datepart-Wert.
LineNumber: 1
Procedure:


2022-05-07T17:33:32 DEBUG - Dauer: 4ms, AffectedRows: 0
2022-05-07T17:33:32 DEBUG - DROP TABLE SCX.tReturnReasonMapping;
2022-05-07T17:33:32 DEBUG - Dauer: 6ms
2022-05-07T17:33:32 DEBUG - IF OBJECT_ID('dbo.tLieferscheinEckdaten', 'U') IS NOT NULL
BEGIN
DROP TABLE dbo.tLieferscheinEckdaten;
END

CREATE TABLE dbo.tLieferscheinEckdaten
(
dErstellt DATETIME NULL,
kLieferschein INT NOT NULL,
dVersendet DATETIME NULL,
nAnzahlPakete INT NOT NULL,
nAnzahlVersendetePakete INT NOT NULL,
nVersandStatus TINYINT NULL,
kVersandArt INT NULL,
nRechnungStatus TINYINT NOT NULL,
fArtikelGewicht DECIMAL(25,13) NOT NULL,
fVersandGewicht DECIMAL(25,13) NOT NULL,

CONSTRAINT [PK_dbo_tLieferscheinEckdaten] PRIMARY KEY NONCLUSTERED (kLieferschein ASC)
);

CREATE UNIQUE CLUSTERED INDEX CIX_dbo_tLieferscheinEckdaten_dErstellt_kLieferschein
ON dbo.tLieferscheinEckdaten (dErstellt DESC, kLieferschein);

ALTER TABLE dbo.tLieferscheinEckdaten WITH CHECK ADD CONSTRAINT [FK_dbo_tLieferscheinEckdaten_kLieferschein] FOREIGN KEY(kLieferschein)
REFERENCES dbo.tLieferschein (kLieferschein)
ON UPDATE CASCADE
ON DELETE CASCADE
2022-05-07T17:33:32 DEBUG - Dauer: 6ms
2022-05-07T17:33:32 DEBUG - ALTER TABLE dbo.tLieferscheinEckdaten CHECK CONSTRAINT [FK_dbo_tLieferscheinEckdaten_kLieferschein]
2022-05-07T17:33:32 DEBUG - Dauer: 0ms
2022-05-07T17:33:32 DEBUG - IF INDEXPROPERTY(OBJECT_ID('Verkauf.tAuftragPositionEckdaten'), 'IX_Verkauf_tAuftragPositionEckdaten_fAnzahlOffen_INCL', 'IndexID') IS NOT NULL
BEGIN
DROP INDEX IX_Verkauf_tAuftragPositionEckdaten_fAnzahlOffen_INCL ON Verkauf.tAuftragPositionEckdaten;
END
2022-05-07T17:33:32 DEBUG - Dauer: 1ms
2022-05-07T17:33:32 DEBUG - IF INDEXPROPERTY(OBJECT_ID('Verkauf.tAuftragPositionEckdaten'), 'IX_Verkauf_tAuftragPositionEckdaten_fAnzahlOffen_fTeilmengenfaktorLager_kAuftragPosition_FILTER', 'IndexID') IS NOT NULL
BEGIN
DROP INDEX IX_Verkauf_tAuftragPositionEckdaten_fAnzahlOffen_fTeilmengenfaktorLager_kAuftragPosition_FILTER ON Verkauf.tAuftragPositionEckdaten;
END
2022-05-07T17:33:32 DEBUG - Dauer: 0ms
2022-05-07T17:33:32 DEBUG - UPDATE Verkauf.tAuftragPositionEckdaten
SET nIstStuecklistenvater = CASE WHEN tAuftragPosition.kAuftragStueckliste = tAuftragPosition.kAuftragPosition THEN 1 ELSE 0 END,
nIstUmlagerung = CASE WHEN tAuftrag.nType = 2 THEN 1 ELSE 0 END,
nPrio = tAuftrag.nLieferPrioritaet,
nPrioDatum = ISNULL(DATEDIFF(SECOND, DATEFROMPARTS(2021, 01, 01), tAuftrag.dErstellt), 0),
kAuftrag = tAuftrag.kAuftrag,
kArtikel = tAuftragPosition.kArtikel
FROM Verkauf.tAuftragPositionEckdaten
JOIN Verkauf.tAuftragPosition ON tAuftragPosition.kAuftragPosition = tAuftragPositionEckdaten.kAuftragPosition
JOIN Verkauf.tAuftrag ON tAuftrag.kAuftrag = tAuftragPosition.kAuftrag
2022-05-07T17:33:32 DEBUG - Dauer: 19ms
2022-05-07T17:33:32 DEBUG - SELECT * FROM tUpdateLog WHERE kUpdateLog > @kUpdateLog
kUpdateLog = 2
2022-05-07T17:33:32 DEBUG - Dauer: 0ms, (bis zum Reader)
2022-05-07T17:33:32 DEBUG - Dauer: 1ms, 0 Zeilen
2022-05-07T17:33:32 DEBUG - Neue Verbindungsparameter: Data Source=WAWISERVER\WAWI;Initial Catalog=eazybusiness;Integrated Security=False;Persist Security Info=True;User ID=sa;Password=;MultipleActiveResultSets=True;Connect Timeout=5;Application Name="4 - B.Eng. Florian Mäck JTL-Wawi C#";Current Language=German
2022-05-07T17:33:32 DEBUG - [TableCache] Invalidate: Full Cache
2022-05-07T17:33:32 DEBUG - SELECT * FROM [tOptions]
2022-05-07T17:33:32 DEBUG - Dauer: 0ms, (bis zum Reader)
2022-05-07T17:33:32 DEBUG - Dauer: 0ms, 130 Zeilen
2022-05-07T17:33:32 DEBUG - SELECT (CASE WHEN SERVERPROPERTY('MACHINENAME') = HOST_NAME() THEN 'local' ELSE 'remote' END) AS instance
2022-05-07T17:33:32 DEBUG - Dauer: 0ms, Result: local
2022-05-07T17:33:32 DEBUG -
USE [master];
ALTER DATABASE JTL_SIM_eazybusiness SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE JTL_SIM_eazybusiness;
2022-05-07T17:33:35 DEBUG - Dauer: 3036ms
Zeitstempel: 2022-05-07T17:34:10
Locale: German (Germany)
Locale: German (Germany)
Version: 1.6.38.0
Plattform: Wawi
WawiSeed: 6.8.68658.47401
Prozessname: JTL-Wawi
Physikalischer Speicher: 293310464 / Peak: 442585088
Basispriorität: 6
Prioritätsklasse: BelowNormal
CPU-Zeit (User): 0:00:08,296875
CPU-Zeit (System): 0:00:02,859375
Page-Size (Sytem): 2544304 / Peak: 509300736
Page-Size: 503332864 / Peak: 509300736
Offene Handles: 1610
Database:
Build: 2205051500 365d5fa7ea4c083c6d98da9e796a681d9704fa05

 

[Pinkman]

warum schreibst Du es hier rein, statt ein Ticket zu machen?
Wer soll Dir hier helfen?

 

[Flow]

Weil andere hier auch bei Update Fehler geschrieben haben. Ich wusste nicht, dass ein Ticket hier der richtige Weg ist. Ich werde eines erstellen...

 

[knackig]

@Flow
Grundsätzlich würde mich und sicherlich auch andere interessieren, wie es weitergeht. Also bitte, halte uns auf dem Laufenden. Den gleichen Schritt hatte ich nämlich auch vor...

 

[Pinkman]

wir sind problemlos auf die 1.6.38 gegangen

 

[NA-Office]

Ich habe das gleiche Problem.
Gibt es einen Lösungsansatz?
Vielen Dank

 

[301Moved]

Ticket aufmachen.
Hab auf einem System auch schon zwei Hänger bei Updates gehabt, die guckt sich JTL schnell an, auch um die auszumerzen nehme ich an. Dann gingen die Updates immer reibungslos.

 

[SebastianB]

Wenn der datediff-Fehler kommt, dann sind Bestellungen mit ungültigem Erstelldatum im System - also (meistens noch nicht gelieferte) Bestellungen vom 1.1.1970 oder ähnliche Datensätze. Das passiert gerne, wenn Fremdconnectoren oder der XML-Import genutzt wird und vergessen wird, die Datumsfelder sauber zu füllen.
Der sauberste Fix ist an der Stelle einmal in der alten Wawi die Bestellungen nach Erstelldatum sortieren zu lassen (vorher den Datumsfilter rausnehmen) und schauen, ob da "exotische" Werte drinnestehen - alles +/- 30 Jahre von heute an sollte funktionieren.

 

[twe]

Das Problem haben wir auch. Es wurden 2 Bestellungen von 2020 über amazon. Bei den Aufträgen ist nur noch das Rechnungsdatum richtig. Hat also nichts mit Fremdconnectoren zu tun.