fetchAll() gibt leeres Array, Looping mit fetch() bekommt alle Ergebnisse

jemand eine Idee, warum dies geschehen würde weirderfetchAll() gibt leeres Array, Looping mit fetch() bekommt alle Ergebnisse

$stmt = $this->prepare($this->sql); 
$exec = $stmt->execute($this->bindings); 
// The below returns an empty array() 
return $exec->fetchAll(PDO::FETCH_OBJ); 
// This however will return rows if looped. 
return $exec->fetch(PDO::FETCH_OBJ);

Selbst ist, dass dies nur mit bestimmten ID-Bereiche in unserer Datenbank geschieht, für Beispiel wenn Sie nach verschiedenen Informationen über ein Element mit der Produkt-ID 552 suchen, funktioniert der obige Code mit fetchAll() kein Problem, aber ändern Sie das zu 553 und es schlägt fehl (leeres Array). 554 funktioniert dann wieder. Es gibt praktisch keinen Unterschied in den Daten innerhalb des DB zwischen den Elementen (es sind nur ganze Zahlen und Zeitstempel [Geolokationsdaten]).

Quelle

2016-07-20 varbrad

fügen Sie einige Debugging: Überprüfen Sie die rowcount für Ihre $ stmt, nachdem es ausgeführt wird. Wenn es einen Fehler gegeben hat, gibt fetch/fetchall boolean false zurück. Wenn es keine Ergebnisse gibt (aber ein gültiges Ergebnishandle), erhalten Sie ein leeres Array. also wahrscheinlich fetch/fetchall arbeitet FINE, und es ist die Abfrage, die irgendwie nichts findet. –

rowCount gibt 23 zurück, columnCount gibt 2 zurück. Weder fetch noch fetchAll geben false zurück. Das Ausführen des rohen SQL-Befehls (emuliert von dem vorbereiteten STMT) funktioniert in der Befehlszeile gut. – varbrad

Ah, hat unseren Server neu gestartet und MySQL gestoppt und neu gestartet und es funktioniert jetzt. Sonderausgabe. – varbrad

Ich dachte, ich würde zurück mit einer Antwort hier, als unser Server heute Abend wieder Schluckauf. Es stellte sich heraus, dass es ein Problem bei der Zeichenkodierung zwischen einem vorherigen Satz von Artikeldaten gab (ich habe buchstäblich keine Ahnung, wofür es vorher codiert war) und die neuere utf-8-Kodierung, die unsere Gegenstandstabelle jetzt verwendet. PHP hängte sich auf mehrere Zeichen auf, die nicht gut konvertiert worden waren (ein paar Rand- und Sonderzeichen), und umgekehrt gab PHP ein Array zurück, das gültig war, aber json_encode konnte nicht damit umgehen und würde das Skript zum Absturz bringen (odd) sowohl in unserer jQuery-clientseitigen Implementierung als auch in unserem eigenen Fehlerüberprüfungs-PHP-Backend (noch merkwürdiger, es wurden mehr Untersuchungen benötigt, aber das liegt außerhalb des Umfangs dieser Frage).

Meine Lösung bestand darin, die Daten direkt aus der API und dem Elementschema in die neue Kodierung zu kopieren, die ursprünglich in utf-8 erstellt wurden, sodass keine Probleme mit der Kodierung entstehen. Getestet mit einer kleinen Teilmenge und das Problem scheint endlich ins Bett gebracht worden zu sein. :)

Quelle

2016-07-20 21:56:07 varbrad

fetchAll() gibt leeres Array, Looping mit fetch() bekommt alle Ergebnisse

Antwort

Verwandte Themen