PHP- Loop vast met een Fetch

[ExploitSolo]

Mijn vraag:
Bij mijn werkgever gebruiken we een planningstool om te zien wie van welk team aanwezig is.
2 weken geleden is deze server gemigreerd van oude omgeving naar een nieuwe omgeving maar sinds die tijd werken 2 pagina's niet meer naar behoren.
Aan de code is niks veranderd (behalve de database inlog gegevens) maar we krijgen nu de foutmelding

Code is destijds door een collega gemaakt welke reeds uit dienst gaat. Kan daar dus niet navragen of hij hiernaar wil kijken.

Foutmelding:

PHP:

 Fatal error: Uncaught Error: Call to a member function fetch() on boolean in /var/www/planner/users.php:35 Stack trace: #0 {main} thrown in /var/www/planner/users.php on line 35

PHP:

while($userrow = $userresult->fetch(PDO::FETCH_ASSOC)) {
    $teamlist = '';
    $teamquery = "SELECT xref_teams_users.id, teams.name, teams.id AS teamid FROM xref_teams_users LEFT JOIN teams ON xref_teams_users.teams_id = teams.id WHERE xref_teams_users.users_id = ".$userrow['id']." GROUP BY teams.id";
    $teamresult = $db->query($teamquery);

    while($teamrow = $teamresult->fetch(PDO::FETCH_ASSOC))

    {
        $teamlist .= "<span class=\"label label-default\"><a style=\"color:white\"href=\"teams.php\">".htmlspecialchars($teamrow['name'])."</a></span>&nbsp;";
    }

Wat ik al gevonden of geprobeerd heb
Gegoogled op foutmelding, geen succes.
Display errors aangezet maar de oorzaak niet kunnen vinden.

Hopelijk kunnen jullie mij zeggen waar deze foutmelding nu opeens vandaan komt. Ik krijg dezelfde foutmelding namelijk ook op een andere pagina.

[ Voor 5% gewijzigd door RobIII op 26-04-2019 09:49 . Reden: Code tags gefixed en overvloed aan indentation verwijderd (scheelt horizontaal scrollen) ]

[RagingPenguin]

Andere versie van php of pdo?

[emnich]

Dit staat er in de foutmelding:

Call to a member function fetch() on boolean in /var/www/planner/users.php:35

Vertaald is dat je een functie fetch probeert te doen op een boolean (true/false) maar een boolean heeft natuurlijk geen functies.

Als je dan op die line kijkt dan zie je dat $db $teamresult dus een boolean is en geen database object.
Vervolgens moet je zelf onderzoeken waarom $db $teamresult false is en geen object.

[ Voor 5% gewijzigd door emnich op 26-04-2019 09:14 ]

[Verwijderd]

De query loopt fout. Zoek bij php.net op errorinfo voor PDO, zet een regeltje in je code, echo dit, en je weet het probleem.

Google op “call to member function fetch on boolean” en google stroomt over met antwoorden...

[ExploitSolo]

RagingPenguin schreef op vrijdag 26 april 2019 @ 08:22:
Andere versie van php of pdo?

Ik heb de 'planningspagina' naar mijn eigen host gedraaid (zodat ik thuis ook ermee kan knutselen/testen, daar werkt het zonder problemen.
PHP versie op werk: 7.2.15
PDO versie: onbekend maar daar is de module pdo en pdo_mysql geladen

PHP versie thuis: 7.2.16
PDO versie: onbekend maar daar is de module pdo, pdo_mysql, pdo_pgsql, pdo_sqlite geladen.

Verder is de code identiek aan elkaar.

emnich schreef op vrijdag 26 april 2019 @ 08:32:
Dit staat er in de foutmelding:

[...]

Vertaald is dat je een functie fetch probeert te doen op een boolean (true/false) maar een boolean heeft natuurlijk geen functies.

Als je dan op die line kijkt dan zie je dat $db dus een boolean is en geen database object.
Vervolgens moet je zelf onderzoeken waarom $db false is en geen object.

Mee eens, maar waarom werkt de zelfde code wel op mijn testomgeving thuis en niet op de productieomgeving op kantoor?

Verwijderd schreef op vrijdag 26 april 2019 @ 08:55:
De query loopt fout. Zoek bij php.net op errorinfo voor PDO, zet een regeltje in je code, echo dit, en je weet het probleem.

Google op “call to member function fetch on boolean” en google stroomt over met antwoorden...

Thanks voor je antwoord maar zie ^^

[Erkel]

Het lijkt mij met de beperkte informatie die beschikbaar is dat de verbinding geweigerd wordt door de database. Zou het kunnen dat de user die gebruikt wordt alleen rechten heeft om te verbinden vanaf het IP van de oude server?

[ExploitSolo]

Erkel schreef op vrijdag 26 april 2019 @ 08:59:
Het lijkt mij met de beperkte informatie die beschikbaar is dat de verbinding geweigerd wordt door de database. Zou het kunnen dat de user die gebruikt wordt alleen rechten heeft om te verbinden vanaf het IP van de oude server?

Nee, zou niet logisch zijn. Dit omdat er maar deel van de pagina's wel te laden is, zonder problemen. (hoofdpagina om roost te zien/in te vullen werkt naar behoren.

[Erkel]

ExploitSolo schreef op vrijdag 26 april 2019 @ 09:00:
[...]

Nee, zou niet logisch zijn. Dit omdat er maar deel van de pagina's wel te laden is, zonder problemen. (hoofdpagina om roost te zien/in te vullen werkt naar behoren.

Ja dat bedacht ik me ook nadat ik op send had gedrukt...

[Erkel]

Kan je misschien de regels posten waar $userresult wordt opgebouwd?

[Groentjuh]

Heb je op kantoor al eens handmatig de opgebouwde query gedraaid. Is de database op kantoor en lokaal identiek.

PDO::query gaat FALSE terug indien deze actie mislukt (of gooit een exception).

[emnich]

Groentjuh schreef op vrijdag 26 april 2019 @ 09:03:
Heb je op kantoor al eens handmatig de opgebouwde query gedraaid. Is de database op kantoor en lokaal identiek.

PDO::query gaat FALSE terug indien deze actie mislukt (of gooit een exception).

Dat ligt aan de settings, als je wil dat hij een exception gooit dan moet TS waarschijnlijk eerst dit doen:

code:

$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

ExploitSolo schreef op vrijdag 26 april 2019 @ 08:57:

Mee eens, maar waarom werkt de zelfde code wel op mijn testomgeving thuis en niet op de productieomgeving op kantoor?

Dat is debuggen . De omgevingen zijn niet gelijk aan elkaar dus moet je onderzoeken wat er anders is of waarom het fout gaat. Je query geeft false terug ipv je resultaten. Nu moet je dus kijken waarom dat zo is (misschien zijn je tabellen niet gelijk, zijn je tabellen in één omgeving case sensitive, etc).

[Verwijderd]

[...]

Thanks voor je antwoord maar zie ^^

Het eerste resultaat van google op SO geeft precies aan hoe je de foutmelding kunt printen. Maar als het “thuis toch draait” en het “dus” niet nodig is, succes met zoeken.

[Freeaqingme]

code:

<?php

false->fetch(PDO::FETCH_ASSOC);

Denk dat dit dezelfde foutmelding op zou leveren. Waarom controleer je niet het resultaat van je function calls/method invocations?

[RobIII]

Doe desnoods op regel 34 een var_dump($teamrow);. Zo moeilijk is 't niet. Maar ik sluit me aan bij de rest: gewoon debuggen. (Debuggen: Hoe doe ik dat?)

[ExploitSolo]

emnich schreef op vrijdag 26 april 2019 @ 09:20:
[...]

Dat ligt aan de settings, als je wil dat hij een exception gooit dan moet TS waarschijnlijk eerst dit doen:

code:

$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Thanks , door het aanzetten van daarvan heb ik de foutmelding gevonden.

SQL mode op 'ONLY_FULL_GROUP_BY' bij werkgever en thuis uit.
Bij werkgever ook uitgezet en werkt nu weer goed.

[Freeaqingme]

ExploitSolo schreef op vrijdag 26 april 2019 @ 10:34:
[...]
SQL mode op 'ONLY_FULL_GROUP_BY' bij werkgever en thuis uit.
Bij werkgever ook uitgezet en werkt nu weer goed.

Heel gek idee, maar waarom niet bij je werkgever aan laten staan en thuis ook aanzetten?

[BertS]

Met ^^
Levert zo te zien een minimale aanpassing in de query op, maar dan heb je het wel béter gemaakt ipv werkend.

[ExploitSolo]

Freeaqingme schreef op vrijdag 26 april 2019 @ 10:57:
[...]


Heel gek idee, maar waarom niet bij je werkgever aan laten staan en thuis ook aanzetten?

Ik zelf mezelf geen PHP developer wil noemen. Ging er voor mij om dat het werkt zoals het voor de migratie heeft gewerkt.