tomquenten

Öhm......ich denke schon. Ich bin beim Testsystem genau nach diesem Schema vorgegangen https://learn.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017&tabs=alpine18-install%2Calpine17-install%2Cdebian8-install%2Credhat7-13-install%2Crhel7-offline#debian17 322 Zeilen, so wie es oben steht. Das werde ich auch noch ausprobieren! Das ich zuerst die Datensätze nur mit Artikelnummer abfrage (dabei bekomme ich die korrekte Anzahl zurück), und in einer Schleife dann jeden einzelnen Datensatz mit allen Details, das funktioniert erst einmal, ergibt aber eben eine Menge (blödsinniger) Anfragen. Nur müssen wir ja erst einmal weiter kommen.

So, habe ich ausprobiert. Gleiches Ergebnis. Das SET NOCOUNT ON brachte auch nichts, da es für Datensatzänderungen gedacht ist. Mir kommt es immer noch so vor, als ob man die abrufbare Datenmenge in Bytes begrenzen könnte. Zwischenzeitlich behelfe ich mir mit einem Workaround, der nicht schön ist, aber wir hier zumindest weiter arbeiten können. Dennoch will ich das Problem verstehen und richtig lösen können, damit dieser Workaroud wieder weg kann. Denn dadurch habe ich eine Vielzahl mehr (sinnlose) SQL Anfragen..... Weitere Ideen sind herzlich willkommen! Vielen Dank tomquenten

Hallo, nachdem ich diese Anfrage letztes Jahr gestellt habe, dachte ich doch tatsächlich das Problem gelöst sei und ich es verstanden hätte. Leider ist dem nicht so. Das Verhalten von MSSQL ist für mich stellenweise mit meinen MySQL Erfahrungen nicht nachvollziehbar. Ich konnte jetzt die letzten 2 Tage soviel experimentieren wie ich wollte, ich kann das noch immer nicht verstehen. Wenn ich jetzt diese Anfrage SELECT a.Artikelnummer FROM KHKArtikel a über den SSMS absetze bekomme ich 956 Zeilen Über PHP per sqlsrv auch 956. Passt! AAABBBEEERRR Wenn ich diese nur leicht modifizierte Anfragen sende bekomme ich über den SSMS wieder 956 Zeilen SELECT a.Artikelnummer, a.Bezeichnung1 FROM KHKArtikel a über PHP aber nur noch 322 Zeilen. Ich habe das jetzt sowohl mit den sqlsrv Treiber 17 und 18 probiert. Bei beiden das gleiche. Mir kommt es so vor, als ob man die abrufbare Datenmenge in Bytes begrenzen könnte. NUR WO? Oder bin ich hier wieder auf dem Holzweg? Ich habe mir die Anfragen über den XEvent Profiler ausgeben lassen, die Anfrage wurden exakt so wie oben beschrieben an die DB gesendet. Der gesamte Testcode ist auf das minimalste begrenzt um Fehler von dieser Seite auszuschließen. Über die Doku von sqlsrv_query habe ich auch was über Options gelesen die per Array mitgegeben werden können. Insbesondere den QueryTimeout. ABER der ist standardmäßig unbegrenzt. Noch jemand eine Idee? Ich bin echt ratlos....und komme so nicht weiter. Vielen Dank! tomquenten

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!!!

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?

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