Neu SQL Abfrage wird mehrfach ausgeführt - Ausgabe in der Übersicht falsch

[Thomas_S]

Mir ist beim erstellen einer eigenen Übersicht aufgefallen, dass die SQL-Abfrage ab einer hohen Anzahl von markierten Einträgen (@Keys) wiederholt wird und damit das Ergebnis falsch ist bzw. das Ergebnis mehrfach ausgegeben wird. Getestet und gegengeprüft habe ich das bei Artikeln und Aufträgen.

Ab welcher Anzahl an markierten Artikeln/Aufträgen das Verhalten auftritt, ist unterschiedlich. Die kleinste Anzahl an markierten Artikeln/Aufträgen, bei der der Fehler bei mir auftrat, lag bei ca. 1.600. Darunter ist die Ausgabe korrekt.

Für mich ist das ein Bug. Ist das noch jemandem aufgefallen?

Simple Beispiele für Artikel

SELECT kartikel
    FROM tArtikel
    WHERE kArtikel IN (@Keys)
    ORDER BY kArtikel ASC

und Aufträge

SELECT kAuftrag
    FROM Verkauf.tAuftrag
    WHERE kAuftrag IN (@Keys)
    ORDER BY kAuftrag

Vielleicht weiß @Manuel Pietzsch mehr?


WaWi 1.7.15.3

 

[kelvin.]

Laut Dokumention von Microsoft kann es bei einigen tausend Werte zu Problemen führen.
https://learn.microsoft.com/en-us/s...in-transact-sql?view=sql-server-ver16#remarks

Ein Workaround wäre laut Doku die Werte in eine Subquery zu packen.

 

[Thomas_S]

Laut Dokumention von Microsoft kann es bei einigen tausend Werte zu Problemen führen.
https://learn.microsoft.com/en-us/s...in-transact-sql?view=sql-server-ver16#remarks

Ein Workaround wäre laut Doku die Werte in eine Subquery zu packen.

Das ist nicht das Problem. Auch ganz ohne Filter in der Abfrage, also ein einfaches SELECT kartikel FROM tArtikel, verursacht den selben Fehler. Im SSMS funktionieren die Abfragen ohne Probleme.

 

[kelvin.]

Kann das auch bestätigen. Habe es reproduzieren können.

Im Profiler habe ich gesehen, dass der in der IN Bedingung nur 2000 Werte übernimmt und dass die Abfrage 5 Mal gestellt worden ist und deswegen in der Übersicht 5 Mal ausgegeben werden.

Es werden aber auch nicht alle Aufträge angezeigt, wenn man den Filter "Alle anzeigen" nutzt.

 

[mvh]

Kann das auch bestätigen. Habe es reproduzieren können.

Im Profiler habe ich gesehen, dass der in der IN Bedingung nur 2000 Werte übernimmt und dass die Abfrage 5 Mal gestellt worden ist und deswegen in der Übersicht 5 Mal ausgegeben werden.

Es werden aber auch nicht alle Aufträge angezeigt, wenn man den Filter "Alle anzeigen" nutzt.

Moin. Ich würde vorschlagen, eine Begrenzung zu verwenden: SELECT TOP (200) kArtikel FROM

 

[Thomas_S]

Moin. Ich würde vorschlagen, eine Begrenzung zu verwenden: SELECT TOP (200) kArtikel FROM

Das wird nicht funktionieren. Ich selektiere 500 und bekomme die Werte für die ersten 200?
Zudem bringt das nichts, wenn man einen Üblick über bestimmter Werte haben möchte, eventuell auch kumuliert. Was sind schon 200 oder auch 1000 Artikel. Das sind am Ende z.B. 20 oder 100 Artikel in 10 Farben. Wenn ich anfangen soll, die SQL Abfragen zu beschneiden, weil es irgendwelche Einschränkungen gibt, kann ich gleich mit der Ameise arbeiten und in Excel rumfrickeln. Dafür gibt es die eigenen Übersichten ja schließlich.

Das Problem das ich sehe, sind die SQLs die kumulierte Werte ausgeben und davon gibt es hier im Forum einige. Da fällt der Fehler nicht so schnell auf. Man vertraut der Abfrage, nimmt die Werte als gegeben aber ein Teil der Artikel/Aufträge wurde nicht berücksichtigt, oder wie hier, mehrfach ausgewertet. Das darf nicht passieren, auch nicht bei mehreren Tausend. Treten Fehler auf oder ist die Schnittstelle überlastet, muss es eine Fehlermeldung geben oder im Zweifelsfall gar keine Ausgabe. Verfälschte Werte aber keinesfalls.

Aber zurück zum Fehler. Wenn man eine einfache Abfrage wie SELECT kartikel FROM tArtikel ohne IN(@Keys) benutzt und nur einen oder wenige selektiert, stimmt das Ergebnis. Ab einer bestimmten Anzahl werden die Werte dann mehrfach ausgegeben. Der Fehler hat also nichts mit der Abfrage an sich zu tun. Das Problem entsteht bereits vorher oder an anderer Stelle.

 

[John]

Gibts da nicht ein Limit, wie groß/lang eine SQL Anfrage sein darf?
Das Problem hat man z.B. auch, wenn man zu viele Artikel in der Auswahl auf einmal aus einer Kategorie per Rechtsklick zu entfernen versucht. Da gibt es (oder gab es früher) eine SQL Fehlermedung.
Vielleicht wird hier aufgeteilt, weil sonst die IN-Bedingung zu viele Elemente hätte. Doof, wenn das Ergebnis deshalb falsch wird.

 

[Thomas_S]

Vielleicht wird hier aufgeteilt, weil sonst die IN-Bedingung zu viele Elemente hätte.

Eventuell, aber warum dann mehrfach die selben Werte bei der Ausgabe? Ich glaube, dass kann nur JTL beantworten.
Ich erstelle dazu morgen ein Ticket. Mal sehen ob ich eine passende Komponente im neuen Support-Formular dafür finde

 

[mvh]

Moin.
Die Query für @key/@keys wird (schon seit immer?) 2-mal verarbeitet, teilweise 2-mal ausgeführt.
Wie oben von Anderen erwähnt, für @keys gibt es nicht nur Einschränkungen seitens JTL - maximal Anzahl an Schlüsseln, maximale "Laufzeit" für Regex-Suche in der Query, usw.
sondern auch von Microsoft: für IN - MS schreibt von Tausenden, wir hatten schon Probleme bei mehr als 2000, überhaupt ist IN-Performance bei vielen Werten sehr schlecht,
Oracle schränkt Werte für IN auf maximal 1000, nicht ohne Grund; für Abfragen/WHERE-Klauseln/ORDER BY/usw.: gelten technisch-/hardware-bedingt Größeneinschränkungen:
s. https://learn.microsoft.com/en-us/sql/sql-server/maximum-capacity-specifications-for-sql-server.