Noch einmal unterschiedliche Ergebnismengen zwischen SSMS und PHP Abfrage

[tomquenten 1]

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

 

[winmadness 78]

Hast Du auch den Hinweis in der sqlsrv_query Doku bzgl. "SET NOCOUNT ON" gelesen. Bezieht sich zwar auf Update-Anweisungen, aber evtl. auch für Dein Problem nützlich.

Bekommst Du das selbe, falsche Ergebniss wenn Du mit sqlsrv_execute arbeitest?

[tomquenten 1]

Am 1.3.2023 um 15:19 schrieb winmadness:

Hast Du auch den Hinweis in der sqlsrv_query Doku bzgl. "SET NOCOUNT ON" gelesen. Bezieht sich zwar auf Update-Anweisungen, aber evtl. auch für Dein Problem nützlich.

Bekommst Du das selbe, falsche Ergebniss wenn Du mit sqlsrv_execute arbeitest?

 

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

[winmadness 78]

Welchen Cursor Type verwendest Du? Verwendest Du den Befehl sqlsrv_num_rows zur Ermittlung der Anzahl Datenätze? Möglicherweise helfen Dir die Ausführungen auf den verlinkten MS Webseiten bei der Fehlerfindung. Evtl. mal den Cursor Typ "SQLSRV_CURSOR_CLIENT_BUFFERED" mit der Option " ClientBufferMaxKBSize" testen (Beschreibung findest Du auf der "Cursor Type" Webseite).

Aus meine Erfahrungen mit ODBC Treibern würde ich auch mal versuchern zuerst den Cursor auf den letzten Datensatz zu positionieren ("SQLSRV_SCROLL_LAST") und dann die Anzahl der Datensätze abzurufen.

Wie sieht Dein Workaround aus?

bearbeitet 3. März 2023 von winmadness

[t-sql 17]

Am 3.3.2023 um 13:26 schrieb tomquenten:

 

Das SET NOCOUNT ON brachte auch nichts, da es für Datensatzänderungen gedacht ist. 

1. SET NOCOUNT ON ist nicht nur für DML gedacht. 

2. Nimmst Du den PHP Treiber von Microsoft? Wenn ja, passt dieser auch zur ODBC Version?

3. Werden im Profiler 956 oder 322 Zeilen beim Aufrufen aus PHP heraus angezeigt?

bearbeitet 8. März 2023 von t-sql

[tomquenten 1]

vor 16 Stunden schrieb t-sql:

Nimmst Du den PHP Treiber von Microsoft? Wenn ja, passt dieser auch zur ODBC Version?

 

Ö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

 

vor 16 Stunden schrieb t-sql:

Werden im Profiler 956 oder 322 Zeilen beim Aufrufen aus PHP heraus angezeigt?

 

 322 Zeilen, so wie es oben steht.

 

Am 3.3.2023 um 14:11 schrieb winmadness:

Aus meine Erfahrungen mit ODBC Treibern würde ich auch mal versuchern zuerst den Cursor auf den letzten Datensatz zu positionieren ("SQLSRV_SCROLL_LAST") und dann die Anzahl der Datensätze abzurufen.

 

Das werde ich auch noch ausprobieren!

 

Am 3.3.2023 um 14:11 schrieb winmadness:

Wie sieht Dein Workaround aus?

 

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.

 

 

[winmadness 78]

Wenn Du die Anzahl der Datensätze nur für die Schleife benötigst, dann würde ich die Schleife anders gestalten. Schaue Dir mal die Beispiele für sqlsrv_fetch_array bzw. sqlsrv_fetch_object an. Hier benötigst Du die Anzahl nicht.

Wenn Du trotzdem die Anzahl benötigst dann ermittle diese wie folgt (Voraussetzung Artikelnummer ist eindeutig):

SELECT count(a.Artikelnummer) as records
FROM   KHKArtikel a

 

bearbeitet 9. März 2023 von winmadness