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

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Front-End Developer – Junior/Medior/Senior

Onze opdrachtgever Onze opdrachtgever maakt kassa’s, personeelsplanning bar-/keukenmanagement, tafelreserveringssoftware, websites en webshops. Van horeca tot retail, van leisure tot zorg: elke ondernemer mag bij hun aankloppen. 24/7 spelen ze proactief in op de markt. Met softwareontwikkeling, projectmanagement, systeemimplementatie, helpdesk en technische dienst in eigen beheer bieden ze zo zekerheid voor haar klanten. Standplaats Hengelo Waar we jou voor nodig hebben? Van sterrenrestaurant tot vakantiepark: de klanten van onze opdrachtgever zijn heel divers. Een intuïtieve orderwebsite voor een grote cateraar of een sieradenplatform voor een juwelier, je draait er je hand niet voor om. Je communiceert helder en staat klanten graag

Bekijk vacature »

Jan te Pas

Jan te Pas

08/12/2018 22:07:21
Quote Anchor link
Ik heb mijn code draaien op het platform van Vimexx, en de update-code werkt prima om een record te updaten. Dezelfde code heb ik op een testplatform gezet, 000webhostapp.com, echter wordt een record niet geüpdatet. Weet iemand de oplossing, of het probleem?
De database heb ik al geopend. De code die ik heb.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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();


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
 
PHP hulp

PHP hulp

21/05/2019 01:39:31
Honeypot
 
- Ariën -
Beheerder

- Ariën -

09/12/2018 01:19:21
Quote Anchor link
Heb je foutafhandeling al aangezet? Geen idee of ej dat ook bedoelt met 'errortrapping' ?
 
Ozzie PHP

Ozzie PHP

09/12/2018 02:36:27
Quote Anchor link
Het einde van de 3e regel klopt in ieder geval niet:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
... $factuurnummer, $toelichting, $showen, $uid) &&
?>


Dat zal dit moeten zijn:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
... $factuurnummer, $toelichting, $showen, $uid);
?>
Gewijzigd op 09/12/2018 02:36:51 door Ozzie PHP
 
Jan te Pas

Jan te Pas

09/12/2018 09:15:54
Quote Anchor link
&& Oeps foutje van het kopieren.

Errortrapping is foutmeldingen aan:
error_reporting(E_ALL);
ini_set('display_errors', 1);
 
Ozzie PHP

Ozzie PHP

09/12/2018 18:11:20
Quote Anchor link
Aha, ik denk dat ik het al zie ...

Vergelijk ...

$ad="UPDATE werkorders SET user=?, klantID=?,

met dit ...

$stmt->bind_param('sssssssssssssssssssssss', $id, $klantid,

Die 'sssssssssssssssssssssss' hoort daar niet.
 
Jan te Pas

Jan te Pas

09/12/2018 18:14:31
Quote Anchor link
Ik heb de routine omgeschreven.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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!";
     }


De foutafhandeling staat aan, geen foutmeldingen.

Echter resultaat is 'Oke!'

Maar.... de update is niet uitgevoerd.

Wie weet hier raad?
 
Ozzie PHP

Ozzie PHP

09/12/2018 18:17:11
Quote Anchor link
Verander

WHERE nummer='$uid'

eens in

WHERE nummer=$uid
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2018 19:10:55
Quote Anchor link
Echo de query eens? Dat is namelijk het SQL-statement wat uiteindelijk wordt uitgevoerd.

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
 
Rob Doemaarwat

Rob Doemaarwat

09/12/2018 19:25:35
Quote Anchor link
Zit je niet in een transaction die niet ge-commit of verderop ge-rollback-ed wordt, of staat toevallig autocommit=0?
 
Jan te Pas

Jan te Pas

09/12/2018 20:03:53
Quote Anchor link
Ik heb in eerste instantie de integers als ‘i’ ingegeven in de goede volgorde. Werkte toen ook niet. Toen las is dat mysql met ‘s’ overal het juiste type van maakt. Ik ga echo proberen en de andere tips. Op beide platformen draait php7.1. ik snap niet waarom het op het ene hostingplatform wel werkt en op de andere niet. Heeft het aantal parameters, velden wellicht nog invloed? Dank voor de tips.
Gewijzigd op 09/12/2018 20:12:38 door Jan te Pas
 
Adoptive Solution

Adoptive Solution

09/12/2018 20:24:45
Quote Anchor link
Als je new mysqli() gebruikt, moet het dan niet zo zijn :

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
$result= $conn->query($ad);
 
Jan te Pas

Jan te Pas

09/12/2018 21:57:52
Quote Anchor link
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 .
 
- Ariën -
Beheerder

- Ariën -

09/12/2018 21:59:56
Quote Anchor link
Gebruik eens $result= $conn->query($ad);
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2018 23:17:12
Quote Anchor link
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.
 
Jan te Pas

Jan te Pas

10/12/2018 08:18:07
Quote Anchor link
&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.

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)
PHP script in nieuw venster Selecteer het PHP script
1
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();    

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
 
Thomas van den Heuvel

Thomas van den Heuvel

10/12/2018 13:34:11
Quote Anchor link
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.
Gewijzigd op 10/12/2018 13:35:03 door Thomas van den Heuvel
 
Rob Doemaarwat

Rob Doemaarwat

10/12/2018 15:15:58
Quote Anchor link
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.
 
Thomas van den Heuvel

Thomas van den Heuvel

10/12/2018 15:34:12
Quote Anchor link
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).
Gewijzigd op 10/12/2018 15:37:36 door Thomas van den Heuvel
 
Jan te Pas

Jan te Pas

10/12/2018 16:37:05
Quote Anchor link
@Thomas,
Hoi Thomas,
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.