[php] prepared statement geeft geen results

[Verwijderd]

ik ben aan het proberen om een aantal queries om te zetten naar prepared statements.

Op zich ging dit goed op mijn dev server thuis maar als ik het op de live server probeer krijg ik geen resultaten terug van de queries... Ik ben nu al uren bezig om uit te zoeken waar het aan kan liggen... maar kom niet echt verder

een simpele statement als dit geeft geen resultaten. Er word niets geupdate, ik krijg ook geen foutmelding.

code:

        $dbconn = mysqli_connect('dbserver', 'dbuser', 'dbpass', 'db') or die(mysqli_connect_error());

        $status = '8';
        $userid = '16';
        
        $stmt = $dbconn->prepare("UPDATE profiletable SET profilestatus = ? WHERE userid = ?");
        $stmt->bind_param('ii',$status, $userid);
        $stmt->execute();

Als ik deze zelfde statement op de "ouderwetse" manier doe is er geen probleem

code:

        $q = "UPDATE  profiletable SET profilestatus = '$status' WHERE userid = '$userid'";
        $r = $dbconn->query($q);

Als ik een select statement doe zonder parameters dan krijg ik gewoon een prima output

code:

        $stmt = $dbconn->prepare("SELECT profilestatus from profiletable order by profileid DESC");
        $stmt->execute();
        $stmt->bind_result($status);
            while ($stmt->fetch()) 
                {
                echo $status;
                }

Dit werkt dus prima.. Op de een of andere manier pakt ie de parameters dus niet mee in de update query (denk ik) maar ik heb echt geen idee meer wat ik fout doe.

[FireDrunk]

probeer in je prepared statement eens '?' ipv ?

[Verwijderd]

Dit levert de volgende foutmelding op:

mysqli_stmt::bind_param() [mysqli-stmt.bind-param]: Number of variables doesn't match number of parameters in prepared statement

[DataGhost]

Waarom definieer je $status en $userid als strings, terwijl je ze later als integer aan het statement voert? Wat me verder ook ontgaat is waarom je aanhalingstekens om die variabelen heen zet in je query, aangezien het integer-types horen te zijn.

[Verwijderd]

Goed punt

Maar ook als ze ik ze als integers definieer veranderd dat nog niets aan de zaak helaas.. ook als ik de vars als strings definieer en ze ook als strings behandel in de query werkt het niet..

Ik heb echt zo'n beetje iedere vorm van notatie en definitie al geprobeerd.

Voor mij is dit echt zo'n head-to-keyboard-smash ding... ik zie niet in waarom die vars niet opgepikt worden in de query... zal vast wel een belachelijk dom iets van me zijn.. maar dat maakt het niet minder frustrerend

[cariolive23]

Er word niets geupdate, ik krijg ook geen foutmelding.

En waar controleer je dan of de query is gelukt en iets heeft geupdate? In bovenstaande code is daar niets van terug te vinden, vrij logisch dat het dan niet werkt.

In de diverse voorbeelden die ik heb gevonden, wordt er eerst een bind_param() aangemaakt en daarná pas de waardes voor de parameters gedefinieerd. Zet de variabelen van regel 3 en 4 eens ná regel 7 (waar je bind_param gebruikt) en probeer het dan nog eens.

Ben blij dat dit met PostgreSQL vele malen eenvoudiger is, pg_query_params() gebruiken, de connectie, query en parameters erin gooien en klaar ben je. Zelfs NULL-values gaan dan goed, dat zal met MySQLi-bind-param nog niet het geval zijn, ga dit maar eens goed testen.

[Verwijderd]

Ik check het in de db via phpmyadmin...

Die vars op een andere plek zetten helpt niet, ook dat had ik al geprobeerd. Zelfs als ik het voorbeeld van php.net gebruik en alleen de vars/veldnamen verander werkt het niet... (overigens worden in dat voorbeeld de vars voor bind_param() gezet)

Dus ik denk dat ik hier toch tegen een soort bug of misconfiguratie op de server aanloop.

Ik ben er zeker van dat het misgaat bij de bind_param.. als ik de variables uit de query weghaal en die vervang voor vaste waardes gaat het prima. Dus op zich is er met de query niets mis..

Zo werkt de query dus prima:

code:

$stmt = $dbconn->prepare("UPDATE profiletable SET profilestatus = 4 WHERE userid = 16");
$stmt->execute();

Zodra ik 1 var toevoeg gaat het mis

code:

$stmt = $dbconn->prepare("UPDATE profiletable SET profilestatus = ? WHERE userid = 16");
$stmt->bind_param('i',$status);
$status = 4;
$stmt->execute();

Van die var een string maken, op een andere plek zetten etc.. het maakt niet uit.

[ Voor 27% gewijzigd door Verwijderd op 03-05-2009 09:30 ]

[Creepy]

PHP:

$stmt->bind_param('i',$status);
$status = 4;

Je zult status eerst een waarde moeten geven en daarna binden, niet andersom.

Edit: Dat hoeft dus niet. Binden kan eerst.

Als ik de voorbeelden zo bekijk dan zou je update query prima moeten werken. Heb je de mogelijkheid op de mysql log aan te zetten en te bekijken? Dan kan je precies zien welke queries MySQL allemaal uitvoert. En close() je je statements wel?

[ Voor 54% gewijzigd door Creepy op 03-05-2009 10:42 ]

[Verwijderd]

Nee, over de logs heb ik helaas geen controle...

de statements doe ik idd wel closen. Ik post hier alleen de code die me hiervoor relevant lijkt om het wat leesbaarder te maken.

[link0007]

misschien eens op een andere server proberen?

[DataGhost]

Even voor de zekerheid, heb je ook gekeken wat er in $stmt->error staat na het executen?

[Verwijderd]

Dat is het vage... er is geen error.. geen php error, geen error vanuit mysqli. Er is niets.

[Voutloos]

Verwijderd schreef op zondag 03 mei 2009 @ 09:17:
Ik check het in de db via phpmyadmin...

En wat zijn de return values van bind_param() en execute()? Controle van system calls moeten gewoon altijd in je code staan, en zeker tijdens het debuggen.

Verwijderd schreef op zondag 03 mei 2009 @ 10:03:
Ik post hier alleen de code die me hiervoor relevant lijkt om het wat leesbaarder te maken.

En test je dit ook zo? Zo nee, maak dan een minimale testcase, zodat je een fuckup in een 'minder relevante regel' kan uitsluiten.

[Verwijderd]

Op dit moment test ik de query zoals ie hierboven staat. Het heeft geen zin om er een heel script omheen te bouwen als ik zelfs het minimale niet aan de praat krijg

Als ik een vardump doe van de bind_param dan krijg ik NULL terug. Precies wat ik verwachte. Op de een of andere manier word de variable niet via bind_param opgepikt en dus ook niet naar de query gestuurd.