Fatal error: Call to a member function fetch_assoc() on a non-object

Door J C op 16-02-2015 01:12 gewijzigd op 16-02-2015 01:18

2.859 views

Ik zit te stoeien met een query. Volgens mij geeft de foutmelding aan dat de query niet klopt, maar ik kan de fout niet vinden, de tabellen, kolommen en db bestaan allemaal. En voor zover ik het kan vinden is INNER JOIN nog steeds toegestaan.

Ik heb de qry ingevoerd in phpmyadmin. Als ik het vraagteken vervang door een waarde, dan werkt het gewoon en geeft hij de juiste gegevens weer.


$qry="
	SELECT
		mw_cursus_onderdeel,
		mw_cursus_onderdeel_id,
		mw_cursus_datum,
		mw_ervaring_groep_naam
	FROM
		mw_cursus_onderdeel
	INNER JOIN
		mw_ervaring_groep
	ON
		mw_cursus_onderdeel_groep=mw_ervaring_groep_id
	INNER JOIN
		mw_cursus
	ON
		mw_cursus_onderdeel=mw_cursus_onderdeel_id
	WHERE
		mw_cursus_persnr=?
	AND 
		mw_cursus_onderdeel_rechten=1
		
";

	$statement = $connection->prepare($qry);				
	$statement->error; //var_dump($statement);
	$statement->bind_param('i', $_GET['mw_id']);
	$statement->execute();
	$statement->store_result();
	var_dump($statement);
	$row_cnt = $statement->num_rows;
	$result = $statement->get_result();	

  if($row_cnt == 0)
		{

		}
  if($row_cnt >= 1)
					{

}
while($basis = $result->fetch_assoc()){
	
  }

de var dump geeft dit weer, weet niet precies wat het betekend

object(mysqli_stmt)#9 (10) {
["affected_rows"]=> int(3)
["insert_id"]=> int(0)
["num_rows"]=> int(3)
["param_count"]=> int(1)
["field_count"]=> int(4)
["errno"]=> int(0)
["error"]=> string(0) ""
["error_list"]=> array(0) { }
["sqlstate"]=> string(5) "00000"
["id"]=> int(7) }

Frank Nietbelangrijk

16-02-2015 09:01

=> mysqli::prepare returns a statement object or FALSE if an error occurred.
=> mysqli_stmt::bind_param Returns TRUE on success or FALSE on failure.
=> mysqli_stmt::execute Returns TRUE on success or FALSE on failure.
=> mysqli::store_result Returns a buffered result object or FALSE if an error occurred.

Hoewel al deze bovenstaande functies (of beter methods) allemaal iets teruggeven doe jij daar helemaal niets mee.

J C

16-02-2015 10:04

Kun je me aangeven wat ik er mee zou kunnen doen? Ik heb een aantal tutorials gevolgd over mysqli, maar de meeste geven aan dat ik het zo zou moeten doen.

Frank Nietbelangrijk

16-02-2015 10:15 gewijzigd op 16-02-2015 10:17

Natuurlijk.

Het is eigenlijk een algemeen verhaal. Functies - eigen gemaakte of standaard PHP - kunnen een waarde retouneren:
<?php
function saySomething()
{
return 'Hello JC';
}

$a = saySomething();

echo $a;
?>

Zo dus ook de bovengenoemde functies.
<?php
$statement = $connection->prepare($qry);
if(!$statement)
echo 'mysqli::prepare gaf FALSE terug!';

$statement->error; //var_dump($statement);

if(!$statement->bind_param('i', $_GET['mw_id']))
echo 'mysqli_stmt::bind_param gaf FALSE terug!';

if(!$statement->execute())
echo 'mysqli_stmt::execute gaf FALSE terug!';
?>

en bij statement store_result gaat het helemaal fout want deze functie geeft het resultaat terug en die heb je dus nodig voor verdere verwerking
<?php
//$statement->store_result();
$result = $statement->store_result();
if(!$result)
echo 'mysqli::store_result gaf FALSE terug!';

var_dump($result);

$row_cnt = $statement->num_rows;
$result = $statement->get_result();
?>

Thomas van den Heuvel

16-02-2015 12:22

Persoonlijk zou ik geen prepared statements gebruiken in combinatie met MySQLi mede (maar niet uitsluitend) omdat je code wolliger wordt, wat de kans op fouten vergroot. Ook het debuggen kost dan vervolgens meer tijd.

Is er een specifiek reden waarom je deze variant hebt verkozen boven het alternatief ((real_)query() icm escapen DATA-delen en filteren van invoer) die, naar mijn mening, schonere (en zeker kortere) code oplevert?

Frank Nietbelangrijk

16-02-2015 12:37

Zeker als de enige parameter $_GET['mw_id'] is in de query en deze nummeriek is zou ik gaan voor intval($_GET['mw_id']) en mysql injection is onmogelijk.

Thomas van den Heuvel

16-02-2015 12:42

Zucht, ja, dan is mysql injection onmogelijk en je query potentieel nutteloos.

Het gebruik van intval is naïef.

J C

16-02-2015 13:03

Thomas van den Heuvel op 16/02/2015 12:22:52

Persoonlijk zou ik geen prepared statements gebruiken in combinatie met MySQLi mede (maar niet uitsluitend) omdat je code wolliger wordt, wat de kans op fouten vergroot. Ook het debuggen kost dan vervolgens meer tijd.

Is er een specifiek reden waarom je deze variant hebt verkozen boven het alternatief ((real_)query() icm escapen DATA-delen en filteren van invoer) die, naar mijn mening, schonere (en zeker kortere) code oplevert?

uhm, om heel kort, maar niet onbeleefd te zijn, omdat ik geen idee heb waar je het over hebt. De bovenstaande methode wordt als veilige manier in de tutorials omschreven.

Thomas van den Heuvel

16-02-2015 13:21

Dat is een manier, maar niet de enige manier.

Als je je bedient van een aantal simpele regels dan kun je MySQLi ook op een veel eenvoudigere manier gebruiken dan al die bovenstaande mumbo jumbo.

prepare
bind_param
execute
store_result
get_result

voor één SELECT query?

Ain't nobody got time for that.

J C

16-02-2015 13:45

Zeker waar, ik zat me er al behoorlijk aan te ergeren dat iets wat vernieuwend zou moeten zijn nu zoveel extra werk moet kosten.

J C

18-02-2015 19:45 gewijzigd op 18-02-2015 19:46

kun je een andere manier beschrijven?

Reageren

Inloggen om te reageren