Archief - SQL: de grootste id of laatst toegevoegd
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
dJeez
Legacy Member
Die functies dienen enkel maar om de waarde van een autoincrement field op te halen van het laatste record dat je tijdens de huidige sessie hebt gecreëerd, ik weet zo nog niet of dat de exacte wens is? Een select max(id) from tabel zal anders ook wel volstaan, maar gebruik dat NOOIT om een nieuwe waarde voor een id te gaan bepalen.
MrO
Legacy Member
mysql_insert_id() is de ENIGE goede manier om dit op te lossen.
Dit haalt de laatste id op die door de huidige instantie van de script is uitgevoerd op. Dus onafhankelijk van hoeveel andere gebruikers er op dat moment mee bezig zijn, je zit altijd juist!
Dit haalt de laatste id op die door de huidige instantie van de script is uitgevoerd op. Dus onafhankelijk van hoeveel andere gebruikers er op dat moment mee bezig zijn, je zit altijd juist!
exxhal
Legacy Member
MrO zei:
Dus ik moet het id ophalen welke is aangemaakt in mijn vorige php script ?
Ik begrijp het niet goed.
Werk ik dan met een sessie?
Het zit nu zo.
Eerst een invulform. welke gegevens plaats in de db.
Dan via een header naar een nieuwe pagina.
Kan ik dan het aangemaakte id meenemen?
Het is mij wel gelukt op deze manier.
HTML:
$qSelect_berichten = mysql_query('SELECT * FROM `invoer`') or die (mysql_error());
while($aBerichten = mysql_fetch_array($qSelect_berichten))
$text = $aBerichten['id'];Waar $text staat voor het bericht in de email.
Dit geeft wel het juiste id weer.
dJeez
Legacy Member
In het eerste script, dus waar je de insert doet kan je - uiteraard enkel indien je ID veld een auto_increment field is - via mysql_insert_id() de waarde ophalen die laatst werd toegekend (let wel op de opmerkingen in de PHP reference, voor BIGINT kolommen mag je die functie NIET gebruiken). De waarde die je dan bekomt kan je dus uiteraard ook in je redirect gaan doorsturen als parameter naar het tweede script, of opslaan in een sessie variabele, of in een cookie zetten, ...exxhal zei:
Aangezien het niet echt duidelijk was wat je wou doen haalde ik ook SELECT MAX() aan, maar voor dit geval is dat dus duidelijk NIET de werkwijze die je moet hanteren - zoals ik ook al specifieerde hierboven
.n00bslayer
Legacy Member
Een transactie is alleen voor queries die ofwel succesvol moeten worden uitgevoerd, ofwel helemaal ongedaan moeten gemaakt worden (denk bvb aan het klassieke overschrijving van één rekening naar een andere-probleem).killgore zei:
Als je iets wil uitvoeren dat afhankelijk is van een onveranderde tabel (tijdens het uitvoeren van deze reeks queries) gebruik je een table LOCK.
WHiSPy
Legacy Member
n00bslayer zei:
Table lock? Zijt ge zeker dat ge dat wilt doen? Beseft ge wel wat een table lock op dat moment doet?
Elk rdbms voorziet functies hiervoor. Als je 'n auto-number/sequence definieert, dan houdt je database sowieso in 'n aparte tabel bij welke de laatst toegewezen id voor die tabel is.
n00bslayer
Legacy Member
WHiSPy zei:
Ik denk nogal multi-user de laatste tijd
en als iemand die laatst gewijzigde Id beïnvloed terwijl je zelf aan het updaten bent, zit je met foutieve data opgescheept. Kans van 1 op je weetwel, maar het zal je maar overkomen. Een exclusive die je de toegang tijdelijk ontzegt kan je overigens perfect opvangen. De kans dat je dit moet opvangen is even klein, maar dan heb je op het einde wel geen foutieve data.WHiSPy
Legacy Member
n00bslayer zei:Ik denk nogal multi-user de laatste tijd
Als je multi-user denkt, dan wil je sowieso geen table lock veroorzaken.
De integriteit van je data is de verantwoordelijkheid van de instellingen van je rdbms en niet van je programmatuur.
n00bslayer
Legacy Member
WHiSPy zei:Als je multi-user denkt, dan wil je sowieso geen table lock veroorzaken.
De integriteit van je data is de verantwoordelijkheid van de instellingen van je rdbms en niet van je programmatuur.
Een voorbeeld van wat ik bedoel, om misverstanden de wereld uit te helpen (door het nut van een table lock uit te leggen):
Gebruiker A wilt een order ingeven. Een order bestaat uit verschillende bestelde items.
Deze gebruiker insert eerst zijn order, om daarna alle bijhorende items te inserten (gekoppeld aan het orderId). Dit orderId kan je achterhalen op allerhande manieren, waaronder mysql_insert_id().
Echter, er is ook een gebruiker B. Deze gebruiker voert zijn order insert uit vlak voordat gebruiker A zijn items die bij zijn order horen, in de database wil inserten.
Als ik mij niet vergis, geeft [SIZE=-1]mysql_insert_id() de meest recente auto_increment weer, en zal deze functie dus de door gebruiker B laatst gegenereerde Id returnen.
Bijgevolg zullen alle order items onder het laatst gegenereerde order vallen, en zal de vorige order geen items hebben.
Om dit te voorkomen gebruik je een table lock. Uitlezen van gegevens heeft tijdens deze lock ook geen zin, omdat nog niet alle items van het laatste order zullen aangevuld zijn wanneer op dat ogenblik bvb een overzicht van alle orders inclusief bijhorende items wordt opgevraagd.
De tijdspanne waar ik het over heb is echt miniem, net als de kans dat dit voorvalt. Maar het is slechts een kleine moeite om dit te voorkomen.
[/SIZE]
killgore
Legacy Member
dJeez zei:Tot er 2 identieke IDs terugkomen omdat die op exact hetzelfde moment worden gegenereerd. Een transactie lost dat probleem overigens niet op. En neem het van mij aan : de kans dat het gebeurt is groter dan je denkt
dat is onmogelijk mits ge met goed beveiligingsniveau en transacties werkt. Kan wiskundig bewezen worden en al
.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.