Ik denk dat je hier een aantal dingen door elkaar gooit.
Met store_result() heb je effectief de query-resultaten (resultset) overgeheveld van de database naar een stuk geheugen in PHP waarin deze query-resultaten worden opgeslagen, dit heet ook wel een buffered result set. Normaal zou je deze vervolgens op kunnen halen uit kunnen lezen met met de fetch() methode.
Wat je vervolgens doet is nogmaals proberen de resultset op te halen middels get_result(), maar deze had je dus al eerder van de database opgehaald als gevolg van een aanroep van store_result(). Aan de database-kant is dus geen data meer aanwezig waarschijnlijk.
Het artikel waar je naar linkt gaat o.a. over bind_result(), niet over store_result() en betreft de verdere een alternatieve afhandeling van het ophalen en verwerken van resultaten.
Oplossing: controleer of store_result() true oplevert en verwijder de aanroep van $result = $statement->get_result().
Een van de andere redenen dat ik prepared statements in MySQLi minder fijn vindt is dat je heel expliciet moet omgaan met queryresultaten waarbij je héél goed in de gaten moet houden of je gebruik maakt van (on)gebufferde resultsets.
Indien je gebruik maakt van ongebufferde resultsets kun je trouwens ook geen gebruik maken van methoden zoals num_rows() en data_seek() omdat de resultaten nog niet binnengehaald zijn door PHP maar record-gewijs worden overgeheveld van database naar PHP. PHP kan je dan niets vertellen over de totale omvang van een resultset en kan hier ook niet doorheen bladeren omdat deze simpelweg niet op voorhand alle resultaten tot zijn beschikking heeft.
Ook, als je 3x het bovenstaande hebt geschreven heb je hier toch schoon genoeg van? Schrijf, als je dan toch volhardt in de gebruikmaking van prepared statements icm MySQLi, een wrapper hiervoor zodat je het jezelf wat makkelijker maakt...
Tevens: waar komt $user vandaan en is dit ook een integer? Je controleert ook niet of het binden van de parameter is geslaagd...
Ik denk dat je hier een aantal dingen door elkaar gooit.
Met store_result() heb je effectief de query-resultaten (resultset) overgeheveld van de database naar een stuk geheugen in PHP waarin deze query-resultaten worden opgeslagen, dit heet ook wel een buffered result set. Normaal zou je deze vervolgens op kunnen halen met de fetch() methode.
Wat je vervolgens doet is nogmaals proberen de resultset op te halen middels get_result(), maar deze had je dus al eerder van de database opgehaald als gevolg van een aanroep van store_result(). Aan de database-kant is dus geen data meer aanwezig waarschijnlijk.
Ok dus die kanik dan weghalen, in dat geval kanik ook niet meet fetch_assoc gebruiken maar wordt het fetch. Zover was ik inmiddels.
Het artikel waar je naar linkt gaat o.a. over bind_result(), niet over store_result() en betreft de verdere afhandeling van het verwerken van resultaten.
Het eerste stuk code wel, maar het tweede stuk code is nagenoeg hetzelfde als wat ik gebruik.
Oplossing: controleer of store_result() true oplevert en verwijder de aanroep van $result = $statement->get_result().
Hiermee is het probleem ook opgelost.
Een van de andere redenen dat ik prepared statements in MySQLi minder fijn vindt is dat je heel expliciet moet omgaan met queryresultaten waarbij je héél goed in de gaten moet houden of je gebruik maakt van (on)gebufferde resultsets. Indien je gebruik maakt van ongebufferde resultsets kun je trouwens ook geen gebruik maken van methoden zoals num_rows() en data_seek() omdat de resultaten nog niet binnengehaald zijn door PHP maar record-gewijs worden overgeheveld van database naar PHP.
Duidelijk
Ook, als je 3x het bovenstaande hebt geschreven heb je hier toch schoon genoeg van? Schrijf, als je dan toch volhardt in de gebruikmaking van prepared statements icm MySQLi, een wrapper hiervoor zodat je het jezelf wat makkelijker maakt...
Dit snap ik niethelemaal, is een wrapper net zoiets als een variable die je steeds weer opnieuw kan oproepen (zoals in min voorbeeld $connection).
Ik heb daar eerder over gehoord, maar heb nog niet eerder een duidelijk uitleg ervan kunnen vinden.
Nu kopieer ik steeds het stukje tekst, als ik het ergens anders nodig heb.
Tevens: waar komt $user vandaan en is dit ook een integer? Je controleert ook niet of het binden van de parameter is geslaagd...
$user is integer. Deze check wordt in het begin van het bestand gedaan via is_int($_POST[úser']).
Hoe check je het beste of het binden van de parameter is gelukt?
Is het nu opgelost of zijn er nog steeds problemen?
Nu kopieer ik steeds het stukje tekst, als ik het ergens anders nodig heb.
Een goed programmeerprincipe is "Don't repeat yourself". Als je eenzelfde handeling vaker uitvoert moet je hier iets mee doen, en daarmee bedoel ik niet knippen en plakken :).
Dit stukej werkt nu dankzij de bind_result, alleen kan ik dit niet toepassen op het andere stuk in het script.
Ben al de hele avond aan het zoeken naar een oplossing.
Ik weet dat het neit altijd handig is om * alle informatie uit een tabel te halen, maar in deze opzet vind ik het wel belangrijk dat alles binnengehaald wordt, ook als ik later nog een extra kollom toevoeg.
Dit werkt prima:
<?php
$mw_gegevens_qry = "
SELECT
*
FROM
mw_gegevens
WHERE
mw_gegevens_persnr=?
AND
mw_gegevens_pass=?
AND
mw_gegevens_pass!=''
";
$statement = $connection->prepare($mw_gegevens_qry);
if($qry === false){
echo "Query error:.". $connection->error();
}else{
$statement->bind_param('is', $user, $userpassword);
$statement->execute();
$result = $statement->get_result();
$mwgegevens = $result->fetch_assoc();
?>
Dit heb ik al uitgelegd: store_result() en get_result() doen min of meer hetzelfde, het enige wat verschilt is: de returnwaarde
store_result() retourneert een boolean, get_result() retourneert een object van de klasse mysqli_result.
hoe je vervolgens de resultaten uitleest
Ingeval je store_result() gebruikt, roep je vervolgens de fetch() methode aan, maar dan moet je ook result-parameters binden blijkbaar om de resultaten echt te vangen, dit is wat nog ontbrak, maar dit is ook vele malen omslachtiger.
Ingeval je get_result() gebruikt, kun je op dit mysql_result object je favoriete fetch-methode loslaten en ook controleren uit hoeveel resultaten deze bestaat et cetera.
Wat jij probeert te doen is deze twee varianten combineren, en dat gaat gewoon niet.
Vergelijk het met de krant uit de brievenbus halen. De tweede keer dat je dit probeert zit er geen krant meer in de brievenbus.
Ik zou voor de get_result() variant gaan omdat deze wat intuïtiever werkt.
Of overstappen naar de variant van MySQLi die niet van prepared statements gebruik maakt, die werkt hetzelfde als de oorspronkelijke MySQL driver (de mysql_-functies).
Of overstappen op PDO als je prepared statements leuk vindt en je het jezelf moeilijker wilt maken om queries te debuggen :p.
Dank je wel, ik begrijp dat ik de 2 methodes niet kan combineren, maar ik krijg num_rows niet werkend zonder de store_result en krijg de fetch_assoc niet werkend zonder de get_result. Als ik echter probeer de get_result weg te halen en de fetch_assoc vervang door fetch, dan werkt het ook niet.
Voer het eens uit zoals je werkende voorbeeld, dus zonder store_result. De query an sich ziet er goed uit, en die geeft zo te zien ook geen foutmeldingen.
Sorry Ik probeer het te begrijpen, maar kom er nog niet helemaal uit.
Ik probeer nu ook verschillende combinaties uit om te kijken hoe ik het werkend kan krijgen.
PDO is voor mij niet echt een optie, daar ben ik mee begonnen, maar kwam er totaal niet uit.
MySQLi zonder statements zou eventueel nog wel een goede optie kunnen zijn.
