Voor mijn stage heb ik een applicatie weten te maken waarin een klantenbestand kan worden bij gehouden. De gegevens worden opgeslagen in een MySQL database.
De gegevens in PHP wijzigen en opslaan werkt d.m.v. een UPDATE-query.
Lokaal werkt dit perfect. Nu heb ik het zojuist online gezet op de Hostnet server - database geëmigreerd, en daarbij connection.php aangepast.
Nu Update hij de gegevens niet meer, en blijven ze ongewijzigd...

Ik denk zelf dat het iets te maken heeft met rechten, maar kom er zelf niet uit, heeft iemand misschien een idee?
Nee natuurlijk niet. Wat denk je van sql logs nakijken en errors printen? Dan zie je het waarschijnlijk meteen...
Hier kan niemand iets mee
Rechten? Het zou kunnen, maar het lijkt mij sterk. Wanneer dat het geval is, dan is jouw script in elk geval niet compleet, de foutafhandeling ontbreekt in dat geval namelijk in zijn geheel. Je krijgt namelijk keurig een foutmelding wanneer je onvoldoende rechten hebt.

Oplossing:
- Inbouwen foutafhandeling (dat is eigenlijk de basis van ieder goed systeem...)
- Echo de query eens die naar de database wordt gestuurd en voer deze query eens uit met phpmyadmin. Wat is daar het resultaat van?
Dat is dus het punt, ik heb een foutafhandeling (daarmee wordt bedoelt iets in de trend van "or die (mysql_error())" ).
Hij geeft hierbij geen fout aan, wanneer ik de query dus ook uitvoer in phpmyadmin (en daarbij de variabelen verander in strings e.d.) werkt het gewoon prima...
en daarbij de variabelen verander in strings e.d.
Dan krijg ik wel een idee waar e.e.a. fout gaat! Echo de query eens, dan krijg je een idee hoe de query er nu precies uitziet.

Foutafhandeling is trouwens véél meer dan 'or die(mysql_error())', dat is voor beginners (geeft niks, die hebben nog een hoop te leren) en prutsers. Een foute query mag er nooit voor zorgen dat jouw hele script om zeep wordt geholpen met die().

Tevens zul je bij een update of delete ook moeten controleren óf er wel iets is bijgewerkt of verwijderd. Daarvoor heb je de functie mysql_affected_rows() nodig.
Een foute query mag er nooit voor zorgen dat jouw hele script om zeep wordt geholpen met die().


Als je bezig bent met het ontwikkelen van je site dat is het meestal wel handig dat je ziet dat een query verkeerd gaat. Op een live site is het inderdaad niet handig om met die()/exit je site om zeep te helpen. Je zou helemaal geen PHP errors op een live site op beeld moeten zetten, dat is alleen maar handig voor hackers/crackers.
Als je bezig bent met het ontwikkelen van je site dat is het meestal wel handig dat je ziet dat een query verkeerd gaat.
Dat wil je ook zien wanneer de boel in productie is. Je wilt het alleen niet op het scherm zien, maar in een logboek. Dat is dus een kwestie van een variabele in jouw configuratie-file aanpassen.

Dit soort zaken doe je als eerste wanneer je een nieuwe systeem gaat maken. Foutafhandeling en beveiliging zijn de basis.
@Frank:
Ja, de logs van Apache/MySQL zijn hier erg handig voor.

Ik zelf heb gewoon een db tabel gemaakt met daarin alle Log berichten. Ik heb een eigen error_handler methode die dan ook berichten in die tabel kan stoppen.
Goed, ik ben er overuit! Het was tenslotte toch het gebruik van variabelen...Deze werden blijkbaar op de local server wel geaccepteerd, en online niet.
In ieder geval bedankt voor jullie advies, hier leer ik nog eens wat van..!

Reageren