mysql_insert_id();
ik heb heel even een vraagje om het command mysql_insert_id()
Ik heb begrepen dat ik hiermee de ID kon ophalen van de laatste insert query die je doet in een script.
echter als ik deze wegschrijf naar een variable dan krijg ik als antwoord 0
iemand enig idee hoe ik dit het beste kan doen ? heb deze ID namelijk nodig voor een volgende query welke bij de volgende query gebruikt moet worden.
heb al een blik geworpen op : mysql_insert_id(); maar helaas word ik daar niet veel wijzer van.
alvast bedankt voor jullie reacties
voorbeeld qeury die ik gebruik
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<?php
//INSERT gegevens in database
$qry3 = "INSERT INTO tablea(colluma,collumb,collumc,) VALUES('$var1','$var2','$var3')";
//Dit is het company ID
$id_qry1 = mysql_insert_id();
$qry4 = "INSERT INTO tablea(colluma,collumb,collumc,collumd) VALUES('$var1','$var2','$var3','$id_qry1')";
?>
//INSERT gegevens in database
$qry3 = "INSERT INTO tablea(colluma,collumb,collumc,) VALUES('$var1','$var2','$var3')";
//Dit is het company ID
$id_qry1 = mysql_insert_id();
$qry4 = "INSERT INTO tablea(colluma,collumb,collumc,collumd) VALUES('$var1','$var2','$var3','$id_qry1')";
?>
Gewijzigd op 19/01/2012 14:46:29 door Marco van Wyngaarden
- Aar - op 19/01/2012 14:47:29:
Je moet uiteraard wel je query eerst uitvoeren ;-)
Ja idd, dus op deze manier:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
<?php
//INSERT gegevens in database
$qry3 = "INSERT INTO tablea(colluma,collumb,collumc,) VALUES('$var1','$var2','$var3')";
$sInsert = mysql_query($qry3);
//Dit is het company ID
$id_qry1 = mysql_insert_id();
$qry4 = "INSERT INTO tablea(colluma,collumb,collumc,collumd) VALUES('$var1','$var2','$var3','$id_qry1')";
?>
//INSERT gegevens in database
$qry3 = "INSERT INTO tablea(colluma,collumb,collumc,) VALUES('$var1','$var2','$var3')";
$sInsert = mysql_query($qry3);
//Dit is het company ID
$id_qry1 = mysql_insert_id();
$qry4 = "INSERT INTO tablea(colluma,collumb,collumc,collumd) VALUES('$var1','$var2','$var3','$id_qry1')";
?>
heb er een zooi van gemaakt tijd om eens te gaan puinruimen.
Mercy Aar. hij pakt hem nu wel uiteraard.
Het voorbeeld wat jij geeft is niet goed.
Ik mis daar foutafhandeling.
Kijk eens in deze tutorial hoe je een foutafhandeling correct toepast. klik
Daarnaast is het beter op bij alle mysql_* functies je resource mee te geven. Dit voor alle zekerheid.
Toevoeging: Variabelen uit de quotes ;-) Lees in de tut die ik je gaf waarom en hoe je dit kunt oplossen.
Niels Kieviet.
Gewijzigd op 19/01/2012 16:06:59 door Niels K
Doe dit bij een insert_id namelijk nooit, want ik weet van me eigen scripts dat er wel een waarde in komt te staan.
Lees dit topic eens door:
http://www.phphulp.nl/php/tutorial/data-verwerking/foutafhandeling-query-sql/735/
Gewijzigd op 19/01/2012 16:10:40 door - Ariën -
Niels Kieviet op 19/01/2012 16:04:19:
Toevoeging: Variabelen uit de quotes ;-) Lees in de tut die ik je gaf waarom en hoe je dit kunt oplossen.
Beste Niels,
Ondanks dat je aanraad variablen buiten quotes te houden is mijn ervaring met SQL query's dat wanneer je in een variable spaties en of speciale tekens heb staan je fouten krijg bij het verwerken van query's. das mijn reden waarom ik mijn variablen altijd in tussen qoutes heb staan
Marco van Wyngaarden op 19/01/2012 16:12:57:
Beste Niels,
Ondanks dat je aanraad variablen buiten quotes te houden is mijn ervaring met SQL query's dat wanneer je in een variable spaties en of speciale tekens heb staan je fouten krijg bij het verwerken van query's. das mijn reden waarom ik mijn variablen altijd in tussen qoutes heb staan
Niels Kieviet op 19/01/2012 16:04:19:
Toevoeging: Variabelen uit de quotes ;-) Lees in de tut die ik je gaf waarom en hoe je dit kunt oplossen.
Beste Niels,
Ondanks dat je aanraad variablen buiten quotes te houden is mijn ervaring met SQL query's dat wanneer je in een variable spaties en of speciale tekens heb staan je fouten krijg bij het verwerken van query's. das mijn reden waarom ik mijn variablen altijd in tussen qoutes heb staan
Als je het goed doet, en logisch kijkt, kan er niks mis gaan.
Nee, or die moet je nooit gebruiken. Lees hoofdstuk 5 van de tutorial die ik gaf eens. Daarin wordt uitgelegd waarom je or die niet gebruiken. Ook wordt er uitgelegd hoe je wel een nette foutafhandeling bouwt.
Ook bij mysql_insert_id moet je foutafhandeling toepassen. Als je op PHP.net kijkt zie je dat mysql_insert_id diversen waarden kan retourneren. Wanneer er iets is fout gegaan retourneert de functie een false (Bijvoorbeeld wanneer er geen connectie aanwezig is). Dat betekend dus dat je moet controleren of de functie geen false retourneert. Wanneer dit wel het geval is mag je de volgende query niet uitvoeren.
Tot slot mag je er nooit van uit gaan of er een waarde in komt te staan. De query kan ook mislukken doordat de (My)SQL server plat is, of bedenk maar een andere reden. Dan gaat de zin: `want ik weet van me eigen scripts dat er wel een waarde in komt te staan` niet op.
Niels Kieviet
Marco van Wyngaarden op 19/01/2012 16:12:57:
Ondanks dat je aanraad variablen buiten quotes te houden is mijn ervaring met SQL query's dat wanneer je in een variable spaties en of speciale tekens heb staan je fouten krijg bij het verwerken van query's. das mijn reden waarom ik mijn variablen altijd in tussen qoutes heb staan
Dat is net zoiets als ob_* gebruiken geen oplossing maar een pleister waarmee je hoopt alles op te lossen.
Als je de query's fatsoenlijk maakt is er geen probleem met spaties rare tekens etc.
Niels Kieviet op 19/01/2012 16:14:39:
Beste Rick de Graaff,
Nee, or die moet je nooit gebruiken. Lees hoofdstuk 5 van de tutorial die ik gaf eens. Daarin wordt uitgelegd waarom je or die niet gebruiken. Ook wordt er uitgelegd hoe je wel een nette foutafhandeling bouwt.
Ook bij mysql_insert_id moet je foutafhandeling toepassen. Als je op PHP.net kijkt zie je dat mysql_insert_id diversen waarden kan retourneren. Wanneer er iets is fout gegaan retourneert de functie een false (Bijvoorbeeld wanneer er geen connectie aanwezig is). Dat betekend dus dat je moet controleren of de functie geen false retourneert. Wanneer dit wel het geval is mag je de volgende query niet uitvoeren.
Tot slot mag je er nooit van uit gaan of er een waarde in komt te staan. De query kan ook mislukken doordat de (My)SQL server plat is, of bedenk maar een andere reden. Dan gaat de zin: `want ik weet van me eigen scripts dat er wel een waarde in komt te staan` niet op.
Niels Kieviet
Nee, or die moet je nooit gebruiken. Lees hoofdstuk 5 van de tutorial die ik gaf eens. Daarin wordt uitgelegd waarom je or die niet gebruiken. Ook wordt er uitgelegd hoe je wel een nette foutafhandeling bouwt.
Ook bij mysql_insert_id moet je foutafhandeling toepassen. Als je op PHP.net kijkt zie je dat mysql_insert_id diversen waarden kan retourneren. Wanneer er iets is fout gegaan retourneert de functie een false (Bijvoorbeeld wanneer er geen connectie aanwezig is). Dat betekend dus dat je moet controleren of de functie geen false retourneert. Wanneer dit wel het geval is mag je de volgende query niet uitvoeren.
Tot slot mag je er nooit van uit gaan of er een waarde in komt te staan. De query kan ook mislukken doordat de (My)SQL server plat is, of bedenk maar een andere reden. Dan gaat de zin: `want ik weet van me eigen scripts dat er wel een waarde in komt te staan` niet op.
Niels Kieviet
Als je aan het developen ben kan je makkelijk een die gebruiken, want anders gaat hij gewoon verder met het bijvoorbeeld inserten in de database.
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
Je hebt een nette manier van afhandelen, maar uit den boze, no way josé
Rick de Graaff op 19/01/2012 16:21:46:
Als je aan het developen ben kan je makkelijk een die gebruiken, want anders gaat hij gewoon verder met het bijvoorbeeld inserten in de database.
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
Oh nee, maak je datastructuur eens kapot. Wedden dat je script opeens vaag zal doen i.p.v. een fatsoenlijke melding tonen.
die() is voor één ding goed. Het hoort op het kerkhof.
Afleren dus.
Rick de Graaff op 19/01/2012 16:21:46:
...
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
...
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
...
Als jij dit kunt garanderen voor een fatsoenlijke prijs vind ik je knap
Nee daar ben ik het niet mee eens. Wanneer je netjes een if / else structuur gebruikt heb je een betere foutafhandeling gerealiseerd. Je kan dan bijvoorbeeld de foutmelding loggen, en noem maar op. Wanneer je een nette if/else structuur gebruikt gaat de applicatie ook niet door, dat heeft niets met de or die methode te maken.
Wanneer je een website oplevert betekend het niet dat hij 100% werkend is. Zoals ik al zei, wanneer de database server down gaat, gaat de or die - mysql_error() methode niet op. Sterkers het kan zelfs heel gevaarlijk zijn.
Tot slot, We besteden hier niet voor niets zoveel aandacht aan. Het is echt slecht om dit te gebruiken.
Niels
Gewijzigd op 19/01/2012 16:26:21 door Niels K
Defensief programmeren. En dat doe je via een goede foutafhandeling.
@Aar, gebruiken we toch exit() :P
Gewijzigd op 19/01/2012 16:27:33 door Jelle -
TJVB tvb op 19/01/2012 16:24:29:
Als jij dit kunt garanderen voor een fatsoenlijke prijs vind ik je knap
Rick de Graaff op 19/01/2012 16:21:46:
...
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
...
Als je de website o.i.d oplevert dan weet je 100% zeker dat alles werkt, dus zijn de die meldingen overbodig, want die komen en er dan niet.
...
Als jij dit kunt garanderen voor een fatsoenlijke prijs vind ik je knap
Als je een goed systeem hebt wel ja. Er word eerst goed getest door mijn mensen en mijzelf.
En ik gebruik de die functie altijd bij een insert. Met een error code erbij, deze kunnen de mensen naar ons sturen zodat wij precies weten waar we moeten zoeken :)
Handig, en toch de die erbij.
Rick de Graaff op 19/01/2012 16:28:12:
Als je een goed systeem hebt wel ja. Er word eerst goed getest door mijn mensen en mijzelf.
En ik gebruik de die functie altijd bij een insert. Met een error code erbij, deze kunnen de mensen naar ons sturen zodat wij precies weten waar we moeten zoeken :)
Handig, en toch de die erbij.
En ik gebruik de die functie altijd bij een insert. Met een error code erbij, deze kunnen de mensen naar ons sturen zodat wij precies weten waar we moeten zoeken :)
Handig, en toch de die erbij.
Die die() is NIET handig. Waarom zou je als er iets fout gaat je hele script laten stoppen?
Geef me eens een reden? HTML wordt afgekapt, e.v.t andere scripts zullen na een die() niet meer uitgevoerd worden. Waarom vind jij het dan nog zo handig?
Naast dat het niet handig is, is het ook nog heel gevaarlijk. Een hacker ziet de foutcode en de SQL waarbij het fout ging ook. Daarop kan hij of zij netjes op voort borduren.
Ik zie namelijk in andere reacties (in andere topics) dat je niet gebruik maakt van het escape van (evt) gevaarlijke input.
Ik raad voor je eigen bestwil nogmaals die tutorial aan.
Niels Kieviet
Rick de Graaff op 19/01/2012 16:28:12:
...
Als je een goed systeem hebt wel ja. Er word eerst goed getest door mijn mensen en mijzelf.
En ik gebruik de die functie altijd bij een insert. Met een error code erbij, deze kunnen de mensen naar ons sturen zodat wij precies weten waar we moeten zoeken :)
Handig, en toch de die erbij.
Als je een goed systeem hebt wel ja. Er word eerst goed getest door mijn mensen en mijzelf.
En ik gebruik de die functie altijd bij een insert. Met een error code erbij, deze kunnen de mensen naar ons sturen zodat wij precies weten waar we moeten zoeken :)
Handig, en toch de die erbij.
Totaal bug vrij is bijna een utopie, get real. Tuurlijk test je alles maar er komen uiteindelijk altijd wel bugs naar voren. Anders heb je zelf ook geen error codes nodig.
Fouten log je en de gebruiker geef je een algemene foutmelding (netjes in de layout van je website waardoor het fatsoenlijk over komt)
Anders word het voor een hacker wel leuker, he nu heb ik een andere foutmelding, waarschijnlijk kom ik verder.
Maar een hacker komt niet in het CMS.
Nee ik geef de die of afhandeling niet op idd, maar moet niet alles voorkauwen toch, en daar is jou handige tut dan weer voor ;)
En voor - Aar -
Alles stopt en de mensen moeten contact met ons opnemen. Klaar, verders niets. Er word geen bewerking meer gedaan.
Maar hier kunnen we lang en breed over praten, maar ik blijf het toch zo doen zoals ik het doe...
En ja dan kan ik idd reacties krijgen van joh stom, niet doen! en hoezo niet..
heeft geen zin, i do it my way.. Logisch toch?
Maar hartstikkje bedankt! :]
Dit topic is gesloten.