PHP: PDO fout bij insert into database

[St@m]

Ik ben bezig met het leren van PHP, gaat moeizaam maar ik ben al aardig op weg denk ik.
Als test heb ik vorige week een database opgezet en daar wat PHP op los gelaten. Ging allemaal perfect.

Van het weekend heb ik OOP een beetje ontdekt, dus braaf als ik ben heb ik al mijn functies herschreven en in class files geplaatst. Dit werkt ook nog.

Nu heb ik een php file waarbij ik via een form een primary key toevoeg aan mijn database. Zo lang ik een unieke pk invoer gaat dit prima, maar wanneer ik een bestaande key toevoeg gaat het natuurlijk mis, dat snap ik en dat hoort ook zo.

Punt is een beetje dat ik bij mijn vorige opzet de volgende code heb gebruikt (deze is al iets aangepast, eerder werd er verbinding gemaakt met de database door middel van een global, maar het idee is duidelijk denk ik):

code:

$stmt = $this->conn->prepare($query);
            $stmt->execute();

            $res = $stmt->rowCount();
            if ($res == TRUE) {
                print("<br><p class=\"ok\"> Item succesvol toegevoegd</p>");
            } else {
                print ("<br><p class=\"error\">Er gaat iets mis, of dit record bestaat al</p>");
            }
        }

Nu is het zo dat ik er maar niet uitkom om het bericht dat wordt gegenereerd in de functie in de class maar niet op mijn scherm krijg (op de pagina van het form dus). De pagina crasht gewoon met de volgende melding:

Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '123' for key 'PRIMARY' in

Maar ik wil gewoon de melding: Er gaat iets mis, of dit record bestaat al, onder mijn form.

De code waarmee ik de class en de functie aanroep

code:

   $add1 = new Additems();
    $add1->addjaar();

Belangrijk om te weten, het is voor eigen gebruik, en ja, de code zal her en der vast niet helemaal netjes zijn, maar ik moet ergens beginnen. Maar ik loop nu echt vast helaas. Mijn form pagina moet niet crashen maar gewoon netjes melden dat ik het even opnieuw moet proberen.

code:

if ($add1 == TRUE) { print "blabla";}

Werkt uiteraard wel gewoon..

[GlowMouse]

http://php.net/manual/en/language.exceptions.php

[St@m]

GlowMouse schreef op dinsdag 17 oktober 2017 @ 23:24:
http://php.net/manual/en/language.exceptions.php

Als je weet waar je op moet zoeken wordt het al een stukje makkelijker Tnx!
Ik ga me morgen eens verder inlezen. Lijkt er inderdaad op dat ik dit nodig ga hebben.

[NMe]

Waarom laat je mensen in hemelsnaam zelf hun primary key verzinnen? Waarom is dat geen autoincrement?

[St@m]

NMe schreef op dinsdag 17 oktober 2017 @ 23:29:
Waarom laat je mensen in hemelsnaam zelf hun primary key verzinnen? Waarom is dat geen autoincrement?

Welke mensen? Mezelf?
Het zijn overigens jaartallen, die zijn uniek dus geen extra id nodig.

En aangezien ik geen aspiraties heb om ontwikkelaar te worden vind ik het wel prima zo. Ik heb een hekel aan iedere tabel een tabel_id te geven omdat dat zo lekker makkelijk is.

Overigens is het geheel een vrij nutteloos stukje code hoor, want het is niet zo dat ik niet weet welke 20 jaartallen er in de tabel staan, of dat ik niet even kan kijken welk jaartal toegevoegd moet worden. Maar het gaat om het algehele principe dat ik een fout krijg bij de insert in de database, die ik begrijp, maar waarvan ik niet weet hoe ik die kan omzetten naar een foutmelding onder mijn form.

[ Voor 51% gewijzigd door St@m op 17-10-2017 23:38 ]

[NMe]

St@m schreef op dinsdag 17 oktober 2017 @ 23:31:
[...]

Welke mensen? Mezelf?
Het zijn overigens jaartallen, die zijn uniek dus geen extra id nodig.

En aangezien ik geen aspiraties heb om ontwikkelaar te worden vind ik het wel prima zo. Ik heb een hekel aan iedere tabel een tabel_id te geven omdat dat zo lekker makkelijk is.

Waarom is, als je toch die instelling hebt, de melding die je nu krijgt niet genoeg dan? Waarom specifiek dit ene ding zo raar aanpakken waardoor je überhaupt die melding krijgt, maar dan wel moeilijk doen over een melding die je zelf toch wel begrijpt? Als je dit bij de bron aanpakt kun je het probleem veel eleganter aanpakken.

[St@m]

NMe schreef op dinsdag 17 oktober 2017 @ 23:48:
[...]

Waarom is, als je toch die instelling hebt, de melding die je nu krijgt niet genoeg dan? Waarom specifiek dit ene ding zo raar aanpakken waardoor je überhaupt die melding krijgt, maar dan wel moeilijk doen over een melding die je zelf toch wel begrijpt? Als je dit bij de bron aanpakt kun je het probleem veel eleganter aanpakken.

Omdat de pagina crasht. Alleen de header wordt nog weergegeven.
Dat is niet de bedoeling. De foutmelding zie ik omdat ik de volgende code heb toegevoegd aan mijn PHP file

code:

ini_set('display_errors', 'On');

Ik wil dus gewoon mijn pagina blijven zien, maar wel weten of het record is toegevoegd, ja of nee.

[ Voor 3% gewijzigd door St@m op 17-10-2017 23:54 ]

[Richh]

Is het niet duidelijker en eenvoudiger om eerst een SELECT te doen en daar te checken of je valide code toevoegt? Afhankelijk van hoeveel users je tool gaat krijgen... een SELECT is niet zo duur.

Daarbij komt de error, duplicate primary key, niet helemaal overeen met wat de bedoeling zou zijn. Je kan in je MySQL database ook velden als 'unique' aanmerken. Dat is wat je wil doen, als ik je goed begrijp primary keys zou ik, tenzij je een zeer goede reden hebt, altijd integers laten zijn die auto-increment zijn.

Maar, mocht je het toch zo willen oplossen: in plaats van klooien met INI_SET en je hele error logging ook voor debugging vervelend maken, zou ik eerder kiezen voor een try-catch mechanisme. Hierbij zet je de database insert in je try{} en vervolg je met een catch{} waarin je deze error kan afvangen en verder afhandelen.
Het is naar mijn smaak niet de schoonste manier om dit te doen (je vertrouwt volledig op je databasemodel), maar, dat zal werken.

[Verwijderd]

Of een INSERT query met een 'ON DUPLICATE KEY UPDATE' clause - lijkt me de minste moeite.

[St@m]

OK, ik word verkeerd begrepen heb ik al door. Jullie gaan in op verkeerde punten die wat mij betreft niet van toepassing zijn.
Ik heb een form, daar vul ik een waarde in, die waarde wordt verstuurd naar de database. Als die gelukt is wil ik de melding 'gelukt' zien en als het niet gelukt is wil ik 'mislukt' zien.
Het form moet altijd zichtbaar zijn.

In mijn vorige functie heb ik dit opgelost door de rijen te tellen. Ik krijg dit niet meer voor elkaar sinds ik classes gebruik. Hoe op te lossen.

Het interesseert me niet wat er precies fout gaat. Ik ben de enige die het gebruikt. Ik weet zelf wel wanneer ik een foutje maak en wat die fout is. Ik kan het vervolgens direct op de goede manier invullen.

Bijvoorbeeld tekst van 200 karakters invullen in een tekstveld van 100 karakters. Dus gewoon generiek iedere keer als ik iets fout doe en de query niet wordt uitgevoerd wil ik dezelfde melding.
Dit had ik dus werkend door rijen te tellen, wat voor mijn toepassing meer dan voldoende is.

[ Voor 33% gewijzigd door St@m op 18-10-2017 00:14 ]

[NMe]

Het is een exeption. Exceptions kun je afvangen. Hoe staat op die pagina van Glowmouse en als je even 2 minuutjes spendeert om dat door te lezen (in plaats van te vragen om aan te wijzen hoe het moet op die hele korte pagina) weet je het.

[ Voor 20% gewijzigd door NMe op 18-10-2017 00:20 ]

[Richh]

Volgens mij krijg je wel degelijk antwoorden, en daarnaast ook nog antwoorden die je op databasegebied verder kunnen helpen in de toekomst

St@m schreef op woensdag 18 oktober 2017 @ 00:08:
Ik heb een form, daar vul ik een waarde in, die waarde wordt verstuurd naar de database. Als die gelukt is wil ik de melding 'gelukt' zien en als het niet gelukt is wil ik 'mislukt' zien.

Try-catch will do that, zoals ik hierboven zei.

*knip*

Komt vrijwel rechtstreeks van de eerste link die je kreeg Modbreak: klopt, en laten we het daarom maar niet helemaal voorkauwen hier.

In mijn vorige functie heb ik dit opgelost door de rijen te tellen. Ik krijg dit niet meer voor elkaar sinds ik classes gebruik. Hoe op te lossen.

Als in:
1. tel rijen, onthoud aantal rijen in $var
2. insert
3. tel rijen, kijk of aantal gelijk is aan $var+1?

Dat werkt, maar dat is vrij omslachtig en bovendien behoorlijk onveilig bij twee inserts op hetzelfde moment. Of je nou classes of niet gebruikt, ik zou met exceptions werken; zoals try-catch.

[ Voor 7% gewijzigd door NMe op 18-10-2017 00:31 ]

[St@m]

Richh schreef op woensdag 18 oktober 2017 @ 00:24:
Volgens mij krijg je wel degelijk antwoorden, en daarnaast ook nog antwoorden die je op databasegebied verder kunnen helpen in de toekomst


[...]

Try-catch will do that, zoals ik hierboven zei.

try {
$stmt->execute();
} catch (Exception $e) {
echo "Dikke vette error!"
}

Komt vrijwel rechtstreeks van de eerste link die je kreeg


[...]

Als in:
1. tel rijen, onthoud aantal rijen in $var
2. insert
3. tel rijen, kijk of aantal gelijk is aan $var+1?

Dat werkt, maar dat is vrij omslachtig en bovendien behoorlijk onveilig bij twee inserts op hetzelfde moment. Of je nou classes of niet gebruikt, ik zou met exceptions werken; zoals try-catch.

Ik was me ook al aan het inlezen en het is me al duidelijk. Maar ik vroeg geen database advies en dat heb ik ook niet nodig hoor ik weet precies wat ik doe en waarom ik het doe in mijn eigen database.
En ik zou ook niet weten waarom ik tegelijkertijd meerdere inserts zou moeten doen.

Ik dacht nog duidelijk te zijn door aan te geven dat dit voor mezelf is, geen andere gebruikers enz.. Maar ja Tweakers..

Dank je wel voor je hulp in ieder geval!

NMe schreef op woensdag 18 oktober 2017 @ 00:19:
Het is een exeption. Exceptions kun je afvangen. Hoe staat op die pagina van Glowmouse en als je even 2 minuutjes spendeert om dat door te lezen (in plaats van te vragen om aan te wijzen hoe het moet op die hele korte pagina) weet je het.

Ik vraag dat helemaal nergens
Altijd prettig om op dit gedeelte van het forum te komen...

[ Voor 16% gewijzigd door St@m op 18-10-2017 00:37 ]

[Richh]

Je zou echt de eerste niet zijn die over een jaar weer een PHP projectje op zou pakken en dan denkt 'oh wacht, daar heb ik nog functies voor' of 'dat heb ik toen zo aangepakt'. Ctrl+c en Ctrl+v en een paar maanden later zegt het opeens krak
Het is echt geen commentaar ofzo, maar dingen juist oppakken scheelt je gewoon tijd in de toekomst.

Dat je, om te kijken of de insert gelukt is rijen telde, en blijkbaar een duplicate primary key aan het inschieten bent, deed mij toch wel een beetje vermoeden dat hulp wellicht toch welkom was

[St@m]

Richh schreef op woensdag 18 oktober 2017 @ 00:37:
Je zou echt de eerste niet zijn die over een jaar weer een PHP projectje op zou pakken en dan denkt 'oh wacht, daar heb ik nog functies voor' of 'dat heb ik toen zo aangepakt'. Ctrl+c en Ctrl+v en een paar maanden later zegt het opeens krak
Het is echt geen commentaar ofzo, maar dingen juist oppakken scheelt je gewoon tijd in de toekomst.

Daarom leer ik het ook in oop (poging tot)

Dat je, om te kijken of de insert gelukt is rijen telde, en blijkbaar een duplicate primary key aan het inschieten bent, deed mij toch wel een beetje vermoeden dat hulp wellicht toch welkom was

Nee, ik probeerde de error weer te geven door een pk in te schieten juist omdat ik zeker weet dat dat fout gaat.

[NMe]

St@m schreef op woensdag 18 oktober 2017 @ 00:31:
[...]
Ik dacht nog duidelijk te zijn door aan te geven dat dit voor mezelf is, geen andere gebruikers enz.. Maar ja Tweakers..

Sommige mensen hebben nu eenmaal wel interesse in het vak dat ze uitoefenen. Als je bij je garage komt vragen hoe je het beste benzine in je dieselauto wil gooien en de monteur raadt je dat ten zeerste af, verzucht je dan ook vermoeid "maar ja, automonteurs?"

[St@m]

NMe schreef op woensdag 18 oktober 2017 @ 00:41:
[...]

Sommige mensen hebben nu eenmaal wel interesse in het vak dat ze uitoefenen. Als je bij je garage komt vragen hoe je het beste benzine in je dieselauto wil gooien en de monteur raadt je dat ten zeerste af, verzucht je dan ook vermoeid "maar ja, automonteurs?"

Een extra id nemen in een tabel waar maar 1 uniek veld inzit is gewoon onzin.
Wellicht had ik dat voorbeeld niet moeten gebruiken hier, maar ik was daarmee aan het testen juist omdat ik dan een foutmelding hoor te krijgen.

En als ik bij de garage kom om mijn koplamp te fixen en de monteur zegt dat ik geen benzine moet tanken met mijn diesel dan verzucht ik inderdaad vermoeid "maar ja, automonteurs"

[ Voor 26% gewijzigd door St@m op 18-10-2017 00:50 ]

[Harrie_]

Ik ben een dagje weggeweest dus kom hier weer lekker laat aanzetten - spuit 11

Ik heb het topic even vluchtig doorgenomen maar volg eigenlijk ook niet zo goed waarom je geen auto-increment ID op die tabel hebt, ookal heeft die tabel maar één unieke waarde. Zeker wanneer je OOP gebruikt aan het leren bent en alles zo generiek mogelijk afvangt is het het toch fijn dat elke tabel een primary key ID heeft waar je, ongeacht met welke tabel je bezig bent, dezelfde standaard acties op uit kunt voeren?

[St@m]

Ok, ik hap toe
Jullie vallen er over dat ik geen extra unieke ID toevoeg aan de tabel.

Waarom ik dat doe heb ik al gezegd: een jaar is immers uniek. Wat mij betreft een reden om een extra uniek ID toe te voegen.

Vertel mij dan eens waarom ik het wel zou moeten doen? I.p.v. roepen dat ik het niet zou moeten doen

De query om een jaar toe te voegen blijft hetzelfde. Als ik een jaar invoer wat niet uniek is zal ik in beide gevallen de melding krijgen dat het niet gelukt is. Wat is de meerwaarde om een extra ID toe te voegen dan?

[NMe]

Toekomstbestendigheid, als je je systeem ooit verandert of uitbreidt waardoor die waarde niet meer uniek is of gecombineerd wordt met een andere waarde dan heb je al ID's die ook dán nog steeds blijven werken.

[Verwijderd]

St@m schreef op woensdag 18 oktober 2017 @ 09:47:
Vertel mij dan eens waarom ik het wel zou moeten doen? I.p.v. roepen dat ik het niet zou moeten doen

Je hebt gelijk: uniek is uniek, dus een extra Id is nergens voor nodig als je weet dat jou veld uniek zal blijven.

Waar je geen gelijk in hebt is dat je van een foutmelding afhankelijk wilt zijn om te bepalen of die key al bestond. Doe dan een SELECT vooraf om te bepalen of je moet toevoegen of niet.

[HamuNaptra]

NMe schreef op woensdag 18 oktober 2017 @ 10:32:
Toekomstbestendigheid,....

Zoals de TS al aangaf gaat het hier om een leertraject waarvan hij duidelijk weet dat er tekortkomingen zijn, geen reden om te blijven doordraven dus...

@St@m Ontdek even verder hoe exceptions werken en hoe je deze best inzet, dit zal je weer een stap verder brengen in je leertraject. Blijf ondertussen goed uitkijken naar wat bepaalde functies teruggeven als return value en probeer hier telkens correct op in te spelen.

[St@m]

Verwijderd schreef op woensdag 18 oktober 2017 @ 12:10:
[...]

Je hebt gelijk: uniek is uniek, dus een extra Id is nergens voor nodig als je weet dat jou veld uniek zal blijven.

Waar je geen gelijk in hebt is dat je van een foutmelding afhankelijk wilt zijn om te bepalen of die key al bestond. Doe dan een SELECT vooraf om te bepalen of je moet toevoegen of niet.

Maar ik wilde ook niet weten of het jaar al bestond, ik wilde weten of de rij succesvol was toegevoegd. Als ik huppeldepup invoer, dan wil ik in eerste instantie weten of de rij is toegevoegd (uiteraard niet overigens).
Ik snap wel wat je bedoelt hoor, en zeker een goede tip.

HamuNaptra schreef op woensdag 18 oktober 2017 @ 12:14:
[...]

Zoals de TS al aangaf gaat het hier om een leertraject waarvan hij duidelijk weet dat er tekortkomingen zijn, geen reden om te blijven doordraven dus...

@St@m Ontdek even verder hoe exceptions werken en hoe je deze best inzet, dit zal je weer een stap verder brengen in je leertraject. Blijf ondertussen goed uitkijken naar wat bepaalde functies teruggeven als return value en probeer hier telkens correct op in te spelen.

Ik ga me er zeker verder in verdiepen en ik zie al heel wat meer mogelijkheden waar ik later meer aan ga hebben

[Verwijderd]

St@m schreef op woensdag 18 oktober 2017 @ 12:27:
Maar ik wilde ook niet weten of het jaar al bestond, ik wilde weten of de rij succesvol was toegevoegd.[...]

In combinatie met de foutmelding die je gaf is dat natuurlijk hetzelfde. En als je wat anders bedoelde had je dat misschien wat duidelijker moeten maken...

Wat 'huppeldepup' betreft kom je dan op het onderwerp validatie: je knalt niet met je vingers in je oren van alles de database in om te zien of het blijft plakken. Als je een jaartal verwacht moet je het bij een invoer als 'huppeldepup' niet eens willen proberen in te voegen.

Als je dat soort elementaire conventies niet wilt volgen is Tweakers denk ik niet de meest geschikte plek voor je vraag, want daar zal op gehamerd blijven worden.

[CurlyMo]

De fout heet niet voor niks een exception en zou dus ook niet gebruikt moeten worden als validation.

[St@m]

Vanmiddag alles helemaal netjes ingeregeld . De controle van @Verwijderd
Validatie en exceptions.
Tnx all