[Solved] Wie weet de oorzaak van het niet updaten msql
De database heb ik al geopend. De code die ik heb.
Code (php)
1
2
3
4
2
3
4
$ad="UPDATE werkorders SET user=?, klantID=?, kostplaats=?, startdatum=?, einddatum=?, werkzaamheden=?, soortwerk=?, werkcode=?, uren=?, peruur=?, basiskosten=?, bijzonderheden=?, totaal=?, offertetotaal=?, voorbereidingtotaal=?, gefactureerd=?, factuurdatum=?, voldaan=?, voldaandatum=?, factuurnummer=?, toelichting=?, showen=? WHERE nummer=?";
$stmt= $mysqli->prepare($ad);
$stmt->bind_param('sssssssssssssssssssssss', $id, $klantid, $project, $startdatum, $einddatum, $werkzaamheden, $soortwerk, $werkcode, $uren, $peruur, $basiskosten, $bijzonderheden, $totaal, $offertetotaal, $voorbereidingtotaal, $gefactureerd, $factuurdatum, $voldaan, $voldaandatum, $factuurnummer, $toelichting, $showen, $uid);
$stmt->execute();
$stmt= $mysqli->prepare($ad);
$stmt->bind_param('sssssssssssssssssssssss', $id, $klantid, $project, $startdatum, $einddatum, $werkzaamheden, $soortwerk, $werkcode, $uren, $peruur, $basiskosten, $bijzonderheden, $totaal, $offertetotaal, $voorbereidingtotaal, $gefactureerd, $factuurdatum, $voldaan, $voldaandatum, $factuurnummer, $toelichting, $showen, $uid);
$stmt->execute();
Ik heb errortrapping aangezet. Geen foutmelding, maar geen update. Wat moet ik veranderen? Dank
Gewijzigd op 10/12/2018 09:48:26 door Jan te Pas
Code (php)
1
2
3
2
3
<?php
... $factuurnummer, $toelichting, $showen, $uid) &&
?>
... $factuurnummer, $toelichting, $showen, $uid) &&
?>
Dat zal dit moeten zijn:
Code (php)
1
2
3
2
3
<?php
... $factuurnummer, $toelichting, $showen, $uid);
?>
... $factuurnummer, $toelichting, $showen, $uid);
?>
Gewijzigd op 09/12/2018 02:36:51 door Ozzie PHP
Errortrapping is foutmeldingen aan:
error_reporting(E_ALL);
ini_set('display_errors', 1);
Vergelijk ...
$ad="UPDATE werkorders SET user=?, klantID=?,
met dit ...
$stmt->bind_param('sssssssssssssssssssssss', $id, $klantid,
Die 'sssssssssssssssssssssss' hoort daar niet.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "dbname";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
$ad="UPDATE werkorders SET user='$id', klantID='$klantid', kostplaats='$project', startdatum='$startdatum', einddatum='$einddatum', werkzaamheden='$werkzaamheden', soortwerk='$soortwerk', werkcode='$werkcode', uren='$uren', peruur='$peruur', basiskosten='$basiskosten', bijzonderheden='$bijzonderheden', totaal='$totaal', offertetotaal='$offertetotaal', voorbereidingtotaal='$voorbereidingtotaal', gefactureerd='$gefactureerd', factuurdatum='$factuurdatum', voldaan='$voldaan', voldaandatum='$voldaandatum', factuurnummer='$factuurnummer', toelichting='$toelichting', showen='$showen' WHERE nummer='$uid'";
$result= mysqli_query($conn,$ad);
// check of geupdated is
if ($result) {
echo "Oke!";
} else {
echo "Not oke!";
}
$username = "username";
$password = "password";
$dbname = "dbname";
// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
$ad="UPDATE werkorders SET user='$id', klantID='$klantid', kostplaats='$project', startdatum='$startdatum', einddatum='$einddatum', werkzaamheden='$werkzaamheden', soortwerk='$soortwerk', werkcode='$werkcode', uren='$uren', peruur='$peruur', basiskosten='$basiskosten', bijzonderheden='$bijzonderheden', totaal='$totaal', offertetotaal='$offertetotaal', voorbereidingtotaal='$voorbereidingtotaal', gefactureerd='$gefactureerd', factuurdatum='$factuurdatum', voldaan='$voldaan', voldaandatum='$voldaandatum', factuurnummer='$factuurnummer', toelichting='$toelichting', showen='$showen' WHERE nummer='$uid'";
$result= mysqli_query($conn,$ad);
// check of geupdated is
if ($result) {
echo "Oke!";
} else {
echo "Not oke!";
}
De foutafhandeling staat aan, geen foutmeldingen.
Echter resultaat is 'Oke!'
Maar.... de update is niet uitgevoerd.
Wie weet hier raad?
WHERE nummer='$uid'
eens in
WHERE nummer=$uid
En id's met type-aanduiding 's', dat rijmt sowieso niet. Het werkt wellicht wel, maar dat schiet dan toch echt zijn doel voorbij als je een parameter die numeriek zou moeten zijn aan het SQL-statement voert alsof het een string is...
Ik zou trouwens id's tussen quotes laten staan, en er zorg voor dragen dat deze alle (inclusief alle andere invoerparameters) ge-escaped worden met een escape-functie. Het een is niet veilig zonder het ander.
Los daarvan, prepare(), bind_param(), execute()... ain't nobody got time for that. Prepared statements van mysqli zijn nogal ruk.
Gewijzigd op 09/12/2018 19:16:16 door Thomas van den Heuvel
Gewijzigd op 09/12/2018 20:12:38 door Jan te Pas
Code (php)
1
$result= $conn->query($ad);
Quote:
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 $uid 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.
Toevoeging op 10/12/2018 09:53:40:
&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:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
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();
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
Gewijzigd op 10/12/2018 09:57:01 door Jan te Pas
Jan te Pas op 09/12/2018 09:15:54:
error_reporting(E_ALL);
ini_set('display_errors', 1);
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.
Gewijzigd op 10/12/2018 13:35:03 door Thomas van den Heuvel
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).
Gewijzigd op 10/12/2018 15:37:36 door Thomas van den Heuvel
Hoi Thomas,
Code (php)
1
2
2
error_reporting(E_ALL);
ini_set('display_errors', 1);
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.