Unterschiedliche Ergebnismengen zwischen SSMS und PHP Abfrage

[tomquenten 1]

Hallo,

 

seit dem ich mir die Sage100 beschafft habe, bin ich dabei die Schnittstellen zu meinen anderen System über die MSSQL Bank herzustellen. Das klappt teils auch schon ganz gut, ich habe sehr viel Erfahrung mit MySQL und LAMP, das hilft hier auch zu verstehen.

 

Ich habe den SSMS installiert, um Abfragen im Problemfall zu testen und die Syntax ggf. zu verbessern. Was ich jedoch technisch nicht mehr nachvollziehen kann ist folgendes Problem. Ich habe über ein Debian System mit srv Treiber eine Abfrage erstellt. Das klappt. Jedoch, zur Fehlersuche gebe ich mir den SQL String vorab nochmal aus, bekomme ich weniger Datensätze als erwartet. Kopiere ich mir EXAKT den gleichen String, den ich zur Fehlersuche ausgebe per Copy&Paste in den SSMS, bekomme ich die korrekte Datenmenge zurück. Über den SQL Server Profiler habe ich das ganze verfolgt. Der SQL String wird korrekt an den Server gesendet, unerwartete Änderungen am String kann ich also ausschließen.

 

Nun habe ich schon eine Menge probiert um der Ursache auf die Schliche zu kommen.

 

SELECT            *
    FROM            KHKArtikel a,
                        KHKArtikelVarianten av,
                        KHKVariantenAuspraegungen ava,
                        KHKPreislistenArtikel pla,
                        KHKPreislisten pl
    WHERE            a.Artikelnummer = av.Artikelnummer
    AND                av.AuspraegungID = ava.AuspraegungID
    AND                av.Artikelnummer = pla.Artikelnummer
    AND                av.AuspraegungID = pla.AuspraegungID
    AND                pla.ListeID = pl.ID
    AND                a.Mandant = 1
    AND                av.Mandant = 1
    AND                ava.Mandant = 1
    AND                pla.Mandant = 1
    AND                pl.Mandant = 1
    AND                pl.ID = '3'
    AND                pla.Einzelpreis > 0
    ORDER BY    a.Hersteller,
                        a.Bezeichnung1

Mit dieser Abfrage erhalte ich 13 Datensätze zurück. Gebe ich exakt die gleiche Abfrage in den SSMS ein, bekomme ich 26 Datensätze. WENN ich jetzt

SELECT            *
    FROM            KHKArtikel a,
                        KHKArtikelVarianten av,
                        KHKVariantenAuspraegungen ava,
                        KHKPreislistenArtikel pla,
                        KHKPreislisten pl
    WHERE            a.Artikelnummer = av.Artikelnummer
    AND                av.AuspraegungID = ava.AuspraegungID
    AND                av.Artikelnummer = pla.Artikelnummer
    AND                av.AuspraegungID = pla.AuspraegungID
    AND                pla.ListeID = pl.ID
    AND                a.Mandant = 1
    AND                av.Mandant = 1
    AND                ava.Mandant = 1
    AND                pla.Mandant = 1
    AND                pl.Mandant = 1
    AND                pl.ID = '3'
    AND                pla.Einzelpreis > 0   

über PHP sende, bekomme ich 24 Datensätze zurück.

 

Wie zum Teufel kann eine Sortierung Datensätze fressen? Das kenne ich von MySQL gar nicht.

 

In den Dokus habe ich folgendes gefunden, was mich nun stutzig macht....

https://docs.microsoft.com/de-de/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15

Die Anzahl der Spalten in der ORDER BY-Klausel ist nicht begrenzt. Die Gesamtgröße der Spalten, die in einer ORDER BY-Klausel angegeben wurden, darf jedoch 8.060 Bytes nicht übersteigen.

 

Könnte mir hier jemand einen Tipp geben??? Ich muss das Problem verstehen können.

 

 

Vielen Dank!

tomquenten

[MDD 12]

Moin,

meine allererste Reaktion wäre zu prüfen ob ich wirklich beides mal die selben Datenbanken und Tabellen (Schemas) abfragen.

 

Dann würde ich prüfen ob via PHP wirklich die selbe Abfrage auf dem SQL landet oder ob der Interpreter was vermurkst. Da hilft der Profiler, die DMV's oder XEvents.

 

Du könntest auch die Daten prüfen und vergleiche ob es Auffälligkeiten gibt die auf einen Cross oder Outer join schließen lassen. Das würde für ich auch die unterschiedlichen Ergebnisse erklären.

Gruß MDD

 

[tomquenten 1]

Hallo MDD,

 

vielen herzlichen Dank für Deine Tipps! Der SSMS ist für mich noch neu, daher konnte ich die Funktion xEvent noch nicht. Ich habe mich dazu belesen können und das jetzt auch ausprobiert. Dadurch bin ich der Sache ein Stück näher gekommen. Durch die xEvents kann ich sehen, welcher String an die DB gesendet wird UND was noch viel wichtiger ist, WIEVIEL Datensätze (row_count) zurück kommen. Das habe ich mit dem Profiler gestern nicht heraus bekommen.

 

Also, der String den ich von PHP aus sende ist, wie oben schon erwähnt, nicht verändert. Er kommt genau so an wie er soll. ABER durch den xEvent habe ich gesehen, das die Rückgabe der Datensätze richtig ist, in php aber weniger ankommen. Ich vermute JETZT, das die srv Treiber für das Debian System für den allerwertesten sind. Ich habe keine andere technisch nachvollziehbare Erklärung mehr.

 

Oder?

[MDD 12]

Kann dir beim PHP leider nicht weiterhelfen.

Logischerweise muss aber entweder die Daten verdichten (z.B. weil durch die Joins 1 Datensatz verdoppelt wird) oder er filtert unter umständen Daten weg. 

Wie gesagt, ich würde die Ergebnisse genau anschauen. Das hilft in vielen Fällen.

 

Aja und im Profiler kann man den rowcount auch mit ausgeben - Einstellungssache.

 

[tomquenten 1]

Hallo MDD,

 

hier nun die Lösung!

 

Es lag an den ODBC / MSSQL Treibern. Ich habe gestern und heute noch sehr viel ausprobiert. JOIN konnte ich zu 100% ausschließen, da ich über xEvent die Anfragen in Echtzeit beobachten konnte. Da ich keine andere Erklärung mehr hatte, habe ich gestern und heute zusätzliche VM´s erstellt. (VMWare sei Dank! - Das macht vieles einfacher) Ich habe zuerst eine VM mit den ODBC 18 Treibern erstellt und meine Scripte kopiert. Schlussendlich kam ich nicht weiter, da ODBC 18 wohl nur noch verschlüsselte Verbindungen zum Server zulässt. Sodann habe ich heute, also soeben, noch eine VM mit den ODBC Treibern 17 installiert und getestet. EXAKT die gleichen Scripte drauf kopiert, gestartet und Voila - alles passt wie es soll. Auch mit den ORDER BY Klauseln verringert sich nicht die Anzahl der Datensätze. Alles Bestens. So soll es sein.

 

Ich danke Dir dennoch vielmals für Deine Hilfe und Hinweisen. Speziell mit dem xEvent, was für mich neu war, konnte ich der Sache Stückchenweise näher kommen.

 

Vielen Dank!!!

[cj_berlin 1.312]

vor 3 Stunden schrieb tomquenten:

Schlussendlich kam ich nicht weiter, da ODBC 18 wohl nur noch verschlüsselte Verbindungen zum Server zulässt.

Das ist nicht korrekt. Bei ODBC 18 ist die Verschlüsselung in der Tat standardmäßig aktiviert. Sie kann aber im Connection String deaktiviert werden, genau dort, wo sie in den früheren Versionen aktiviert werden konnte.