Ik krijg wel contact met de database, want de gevraagde id wordt opgehaald.
Maar ik krijg steeds de melding dat er geen rijen gewijzigd worden, terwijl ik wel andere waarde invoer.
Ik heb geen idee meer wat ik fout doe.
Het eindresultaat van een UPDATE-statement kan best zijn dat er effectief niets gewijzigd wordt, in dat geval retourneert rowCount() standaard 0. Je kunt dit gedrag wijzigen door de connectie optie PDO::MYSQL_ATTR_FOUND_ROWS met de waarde true toe te voegen.
Maar jij zegt dat je waarden echt inhoudelijk wijzigt. Wordt deze wijziging ook echt doorgevoerd in de database? Zoja, dan gaat er niet echt iets fout en zou ik de aanpak wat veranderen, numRows() is dan blijkbaar geen goede controle, kun je in dat geval niet gewoon kijken of execute() true teruggeeft?
En ja, als je het effect van een wijziging helemaal niet terugziet zul je verder moeten kijken waar dit vandaan komt uiteraard.
Een UPDATE-query uitvoeren waarin niets gewijzigd wordt is in ieder geval niet per definitie fout.
M.i. moet er een fout in het script zitten.
Ik wijzig in het formulier de waarde 'auth' en 'period' van 0 naar 1.
In feite is dit een wijziging van false naar true, met een integer-waarde 0 en 1.
Ik krijg de melding terug dat er 'geen rijen gewijzigd zijn', en heb gecontroleerd dat er effectief in de database geen rijen gewijzigd zijn. Dus de wijziging komt niet door. Maar ik zie werkelijk niet waar de fout zit.
Heb je PDO wel zo ingesteld dat deze gebruik maakt van exceptions als foutmeldingsmethode? Dit doe je ook middels een connectie optie PDO::ATTR_ERRMODE met als waarde PDO::ERRMODE_EXCEPTION.
EDIT: hoe luidt de definitie van de tabel, als die kolom een ENUM is moet je de waarde wellicht voorzien van quotes, en mogelijk doet PDO dat zelf niet of zoiets? Je zou altijd kunnen overwegen om tijdelijk query-logging aan te zetten (volgens mij de enige manier om te achterhalen welke concrete queries er daadwerkelijk worden uitgevoerd).
Heb je PDO wel zo ingesteld dat deze gebruik maakt van exceptions als foutmeldingsmethode? Dit doe je ook middels een connectie optie PDO::ATTR_ERRMODE met als waarde PDO::ERRMODE_EXCEPTION.
EDIT: hoe luidt de definitie van de tabel, als die kolom een ENUM is moet je de waarde wellicht voorzien van quotes, en mogelijk doet PDO dat zelf niet of zoiets? Je zou altijd kunnen overwegen om tijdelijk query-logging aan te zetten (volgens mij de enige manier om te achterhalen welke concrete queries er daadwerkelijk worden uitgevoerd).
Ja, dat staat aan.
Ik weet niet precies wat je bedoelt met ENUM. Ik heb getest of er een verschil is in het gebruik van <input type="radio" name="period" value="1" /> of <input type="radio" name="period" value=1 />. Maar dat maakt niets uit, de rijen blijven ongewijzigd.
Het rare is dat de query wél werkt op de lokale wamp-server. Het enige verschil dat ik heb kunnen vinden is dat ik thuis op wamp MySQL 5.6.17 heb en de provider 5.5.47 gebruikt. Kan het daar aan liggen???
De kolomwaarden trouwens zijn ingesteld als tinyint en NOT NULL
Ik bedoelde quotes in de query. Waar je normaal niets mee doet omdat de prepared statements laag dit doorgaans voor je regelt.
Misschien is het zoiets sufs als de volgorde van de parameters zoals je die in de query gebruikt en de volgorde zoals je die meegeeft aan het execute-array (deze verschillen van elkaar), maar bij named parameters zou dat toch niet uit moeten maken?
Ook is het volgens mij geen gereserveerd woord, maar je zou kunnen proberen de kolomnamen in je query te voorzien van `backticks` (al ben ik daar geen fan van).
Ik zie het anders ook eigenlijk niet, ik vrees dat je -als het bovenstaande het niet oplost- toch de mysql-logs in moet duiken ofzo. Je zou ook kunnen overwegen om gewoon van die numRows() check af te stappen, al zou je query natuurlijk wel gewoon dingen moeten updaten :/.
EDIT: mogelijk zit de informatie niet (goed) in $_SESSION of $_POST, dump deze twee arrays eens, die geven inzicht hoe je uiteindelijke query er mogelijk uit ziet. Misschien ontbreekt $_SESSION['id'] per ongeluk ofzo, en dan wordt er niets geupdate ;).
Uiteindelijk de oplossing gevonden door het Session-id terug in het formulier te zetten en als Post-id in de query te verwerken.
Dit werkt wel. $_SESSION['id'] wordt om de één of andere reden niet verwerkt door de providers versie, waar WAMP dat wél doet.
Bedankt voor het meedenken.
@Ivo: Je hebt gelijk. $_SESSION['error'] werkt inderdaad niet.
En schuif ik de session_start naar beneden, dan krijg ik inderdaad de cannot start session, headers already sent melding. Ik heb alles nagezocht en kan niet vinden dat er html-uitvoer is, voordat ik dit script uitvoer. Tenzij het probleem gegenereerd wordt omdat ik iedere pagina via een GET['page'] op de indexpagina oproep. De headers already sent meldt de sent op de laatste regel van de file "metadata".
Als je bedoelt dat de code hierboven de uitvoer is die in de file metadata naar de browser gestuurd wordt: ja dat is uitvoer.
het is zelfs html.
Maar als stuurde je een cijfer, of een of ander vaag chinees teken in unicode: uitvoer is uitvoer.
zodra jij uitvoer stuurt, en je gebruikt geen output buffering, dan zegt Apache:
"he browser, hier komt wat data. En deze data moet je zien als een stukje html of gewoon tekst."
Je kunt ook een http-server laten zeggen: "deze data is binair en je kunt er een plaatje van maken".
ofwel : header('Content-Type: image/jpeg');
In elk geval:
dit is nu geroepen en 1 of meer bytes aan data zijn verzonden.
Nu kom jij aan met session_start();
Nu moet Apache nog iets gaan roepen "he browser, de header die ik net stuurde over dat het html is, daar had ik nog iets over een cookie bij willen zeggen".
Ja en dat gaat dus niet meer...
---
Als het op jouw wamp server wel werkt, moet je eens nazoeken of output buffering aan staat.
Dat betekent dat je Apache de eerste x kB aan data op laat sparen voor je de output en de headers begint te versturen.
(is een bron voor bugs: zoals hierboven, maar ook dat je scripts prima werken voor
Jon Doe op plein 1 in Dorp
maar niet voor
Baron van Hier tot daar op de Laan van Meerdervoort in 's-Gravenhage
omdat je dan ineens over de buffer size heen gaat.
Output buffering uitzetten en je script logisch opbouwen:
eerst invoer afhandelen, route bepalen in je script, data klaar zetten en pas dan denken aan wat er naar het scherm gaat moeten