[Solved] Wie weet de oorzaak van het niet updaten msql

Zojuist ook de echo controle van de query aangepast en bekeken. Alle variabelen zijn ingevuld en staan goed. En toch wordt de tabel niet aangepast. iNSERT query met nieuwe parameters werkt gewoon zoals het moet. $result geeft ‘OKE’. Oplossing is er of niet .

Gebruik eens $result= $conn->query($ad);

Toen las is dat mysql met ‘s’ overal het juiste type van maakt.

Dat lijkt mij niet kloppen. Het effect van alle invoer behandelen als string is waarschijnlijk dat deze niet meer struikelt over numerieke kolommen als deze geen numerieke waarden toegewezen krijgen. Dat levert dan misschien wel een query op die qua vorm (syntax) correct is, maar qua betekenis (semantiek) nooit iets werkends zal opleveren. Door alles te behandelen als string veeg je dus potentiële problemen onder het tapijt.

Mijn eerste ingeving zou dan ook zijn als je UPDATE niet werkt, dat op een of andere manier je WHERE-conditie een onzinnige waarde heeft...


... Sterker nog, weet je zeker dat je $id en $[color=#ff0000]u[/color]id niet hebt omgedraaid? Het lijkt mij dat $uid eerder een user id impliceert, en $id meer lijkt op een nummer, al is deze laatste omschrijving redelijk inhoudsloos.

Het verschil kan worden verklaard met dat je lokaal waarschijnlijk meer testdata hebt ofzo? Maar dan nog zou eigenlijk meteen moeten blijken dat er weliswaar een record wordt geupdate, maar het verkeerde - tenzij je dus consequent bent in deze verwisseling tussen $id en $uid.

Daarnaast is user een gereserveerd woord, dus deze zou tussen `backticks` moeten staan.

Misschien wordt er ook op het ene platform MySQL gebruikt, en op de andere MariaDB? Deze laatste is mogelijk kritischer over zaken.

&Thomas: Dank voor de toevoeging. Ik heb al heel veel checks uitgevoerd. Maar ik ga er nog een keer, met deze kennis, met een stofkam doorheen. Beide platformen zijn online. De testdata zitten alleen in 000webhostapp.com. In de laatste code die ik gebruik, is zonder de "bind_param('issss" etc. gedaan. Ik check nog eens alles. Dank voor de richting. Ik laat het weten.

[size=xsmall]Toevoeging op 10/12/2018 09:53:40:[/size]

&Thomas, maar ook anderen: Opgelost. Er zit een verschil in platform. Wat een leek ben ik. MariaDB is inderdaad kritischer. Stofkam er doorheen en extra test er tussen gezet en toen stap voor stap elke variabele getest:

	if ($conn->query($ad === TRUE) {
		echo '<script type="text/javascript">alert("De order verwerkt!");</script>';  
  	} else {
		echo "Error: " . $ad . "<br>" . $conn->error;
		echo '<script type="text/javascript">alert("De order is niet verwerkt! Probeer het nog eens!");</script>';
  	}
  	$conn->close();	

Een leeg $voldaandatum-veld was de oorzaak. En die werd pas in sommige gevallen gevuld. Ik heb dit aangepast, en No problemo. Dank allen.

Weer een hoop geleerd!!
Jan

En om nog een mogelijk misverstand de wereld uit te helpen, dit:

Jan te Pas op 09/12/2018 09:15:54

error_reporting(E_ALL);
ini_set('display_errors', 1);

gaat over het registreren en weergeven van fouten in PHP-code. Dit gaat niet over queries die mislukken. Je zult zelf op een of andere manier moeten controleren of een query fout gaat.

In eerste instantie kun je dus -zoals je zelf al gezien hebt waarschijnlijk- met behulp van de return-waarde van de functie mysqli_query() vaststellen of een query geslaagd is. Hier wil ik nogmaals benadrukken hoe belangrijk documentatie is. Heel vaak geeft een return-waarde (onder het kopje Return Values) informatie over de toestand van je code. Retourneert mysqli_query() de waarde true dan betekent dit dat de query syntactisch correct was en is uitgevoerd. Retourneert mysqli_query() false dan betekent dit dat de query syntactisch niet klopte (en daardoor niet uitgevoerd kon worden en ook niet uitgevoerd is). Bij het inspecteren van deze waarde sta je dus al in wezen op een kruispunt (in het geval de query blijkbaar niet het gewenste effect heeft):
- moet ik de query inhoudelijk verder inspecteren, of
- moet ik de waarden die in de query worden gevoegd verder bestuderen

Als je dus kennis neemt van deze informatie kun je hiermee heel snel je zoekgebied afbakenen en verkleinen waarmee je dus enorm snel inzoomt op de veroorzaker van het ongewenste gedrag.

In het geval er false werd geretourneerd vertelt MySQL jou waarom deze de query niet kon uitvoeren met behulp van mysqli_error(). In een productie-omgeving wordt je dan meestal doorgestuurd naar een "Oops the server made a booboo" pagina, wordt de error gelogd, en gaat er meestal een bericht (of e-mail) uit naar een monitor-proces ofzo. In een live website zouden dus geen dingen als "or die(mysqli_error())" moeten staan ofzo, zoals men vroeger placht te doen.

In het geval er true werd geretourneerd wordt het tijd om de query zelf inhoudelijk te debuggen. En daarom heb ik persoonlijk een broertje dood aan prepared statements - dit maakt het praktisch onmogelijk om (snel) te zien hoe de uiteindelijke query die wordt uitgevoerd er uitziet, tenzij je misschien al je queries gaat loggen en dan in die logs gaat graven maar dat is allemaal vreselijk omslachtig.

En dan is er nog een ander aspect: voordat al die DATA sowieso in een SQL-string geplaatst wordt zou deze voor de goede orde al onderworpen moeten zijn aan een stricte validatie. Als de DATA niet voldoet aan de door jouw opgestelde regels dan zou er in eerste instantie geen query uitgevoerd mogen worden. Alle DATA moet kloppen voordat er ook maar een poging wordt ondernomen om deze aan de database te voeren, anders bestaat er de kans dat er rommel in je database terecht komt en als je daar pas na verloop van tijd achter komt dan heb je al helemaal stront.

Bij PDO kun je in ieder geval $pdo->setAttribute(\PDO::ATTR_ERRMODE,\PDO::ERRMODE_EXCEPTION); Je hoeft dan geen return value te checken, want je krijgt gewoon een exception in je mik. Geen idee of zoiets ook voor mysqli bestaat.

Voor mysqli bestaat iets soortgelijks, er is een mysqli exception class. Maar je hele code moet dan wel ingericht zijn om van dit exceptions-stramien gebruik te maken. Een niet-gevangen exception produceert nog altijd een fatal error.

Een (ander) alternatief is een schil om je mysql(i)-functionaliteit te schrijven, wat in zekere zin sowieso een goed idee is omdat je op die manier hard coding voorkomt. In deze schil kun je tevens besluiten/programmeren (of wederom via een exception propageren) wat er moet gebeuren indien er een fout optreedt.

Zo trek je in ieder geval eventuele foutdetectie en -afhandeling uit lopende code wat in het algemeen wel een goede zaak is (separation of concerns).

@Thomas,
Hoi Thomas,

error_reporting(E_ALL);
ini_set('display_errors', 1);

was in dit geval niet in de roos. Dus wat jij zegt klopt helemaal. Pas toen ik de query, stuk voor stuk, echt ging checken, kwam het aan het licht. Maar op deze wijze leer ik wel heel veel. Dus wederom dank voor de extra les.