DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Wat is het type van het veld waar de auto_increment op staat? Als dat bijvoorbeeld TINYINT is, dan is het logisch dat hij niet verder gaat: een TINYINT kan waarden aannemen van -128 tot 127. Dan zou je het type moeten aanpassen naar een groter datatype.quote:Op zondag 23 november 2008 11:19 schreef MrDoegewoon het volgende:
Klein MySQL vraagje,
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Ik heb geprobeerd hem te resetten, maar niks hielp. Wel fixte een repair van die tabel het probleem. Maar mijn vraag is, hoe kan dit gebeuren? Dat de auto_increment value blijft hangen.
Uitleg over datatypen: http://dev.mysql.com/doc/refman/5.0/en/numeric-types.html
Wat is sneller/beter/logischer?
Ik wil een UPDATE uitvoeren, echter wanneer de record nog niet bestaat moet het een INSERT zijn.
Dit kan op twee manieren:
- Met SELECT zoeken naar de record, indien deze bestaat een UPDATE uitvoeren, indien deze niet bestaat een INSERT.
- Met DELETE de record verwijderen, ongeacht of deze bestaat (dus zonder een SELECT) en vervolgend een INSERT.
Ik wil een UPDATE uitvoeren, echter wanneer de record nog niet bestaat moet het een INSERT zijn.
Dit kan op twee manieren:
- Met SELECT zoeken naar de record, indien deze bestaat een UPDATE uitvoeren, indien deze niet bestaat een INSERT.
- Met DELETE de record verwijderen, ongeacht of deze bestaat (dus zonder een SELECT) en vervolgend een INSERT.
ne okuyon, bokmu var?
Of altijd een insert proberen te doen en ON DUPLICATE KEY UPDATEquote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
Zoals hierboven ook al staat: je gebruikt een signed TINYINT datatype (unsigned gaat 'ie tot 255, dus voor auto_increments altijd unsigned gebruiken, dubbele capaciteit en je gaat toch nooit in het negatieve). Lekker INT van maken, kun je er (unsigned) 4294967295 kwijtquote:Op zondag 23 november 2008 11:19 schreef MrDoegewoon het volgende:
Klein MySQL vraagje,
Op één van m'n websites gaf een script ineens een MySQL error, de auto_increment value bleek op value 127 te hangen.
Thanks!quote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
ne okuyon, bokmu var?
Het verhaal van de signed tinyint verklaart niet waarom een REPAIR TABLE het probleem verhielp. Normaal gesproken zijn auto_increment kolommen heel betrouwbaar: zie de topicnummers/postnummers/userid's hier op FOK!, op GoT, en op vrijwel ieder ander forum.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Fout, REPLACE INTO verwijderd eerst het gevonden resultaat en INSERT INTO .. ON DUPLICATE KEY doet dat niet, deze past het resultaat alleen maar aan.quote:Op zondag 23 november 2008 14:38 schreef Xcalibur het volgende:
het enige juiste antwoord: REPLACE INTO
Dus het is niet het enige juiste antwoord, maar een mogelijk antwoord.
Zie trouwens oon de opmerking over delete cascade in de docs: http://dev.mysql.com/doc/refman/5.0/en/replace.html
In theory there is no difference between theory and practice. In practice there is.
Gezien de vraag lijkt dat geen probleemquote:Op zondag 23 november 2008 15:10 schreef slacker_nl het volgende:
Fout, REPLACE INTO verwijderd eerst het gevonden resultaat en INSERT INTO .. ON DUPLICATE KEY doet dat niet, deze past het resultaat alleen maar aan.
Beide opties zijn overigens beter/sneller dan een select + update danwel delete + insert
Snap ik, maar vreemde is dat de counter pas op 52 hoorde te staan ipv 127.quote:Op zondag 23 november 2008 14:47 schreef CraZaay het volgende:
[..]
Zoals hierboven ook al staat: je gebruikt een signed TINYINT datatype (unsigned gaat 'ie tot 255, dus voor auto_increments altijd unsigned gebruiken, dubbele capaciteit en je gaat toch nooit in het negatieve). Lekker INT van maken, kun je er (unsigned) 4294967295 kwijt
West Ham supporters, check: Dutchirons
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
Dutch Football Manager Site!
Determined to deliver, destined to dominate. - The Third Movement
| 1 2 3 | <input type="checkbox" name="details" value="1" if($edit_details==1){ echo'checked="checked" disabled="disabled"';} /> ?> |
Waarom is na de submit $_POST['details'] not set als in bovenstaande regel de if true is :?
Kijk eens in de HTML-output van je bovenstaande stukje code
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
<input type="checkbox" name="details" value="1" checked="checked" disabled="disabled" />
hij staat dus ook keurig aangevinkt en greyed out.
hij staat dus ook keurig aangevinkt en greyed out.
Ah, ik zag geen PHP-tag halverwege je regel dus dacht dat daar het probleem zat. Maar disabled wordt niet doorgegeven inderdaad. Alternatief is readonly, maar dat werkt in Firefox in ieder geval niet goed. Ander alternatief is met een script vlak voor de submit het veld nog te undisablen.
Maar beter nog is helemaal niet naar deze waarde te kijken, maar gewoon in je script te bedenken wat de waarde zou moeten zijn. User-input is immers nooit te vertrouwen.
Maar beter nog is helemaal niet naar deze waarde te kijken, maar gewoon in je script te bedenken wat de waarde zou moeten zijn. User-input is immers nooit te vertrouwen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Waarom heb je uberhaupt de waarde van een checkbox nodig als je hem niet kunt wijzigen? 
Lijkt wat zinloos...
Lijkt wat zinloos...
Opgelost met een hidden veld. Jammer dat 'readonly' IE only is. handige html tag.quote:
Ah, ik zag geen PHP-tag halverwege je regel dus dacht dat daar het probleem zat. Maar disabled wordt niet doorgegeven inderdaad. Alternatief is readonly, maar dat werkt in Firefox in ieder geval niet goed. Ander alternatief is met een script vlak voor de submit het veld nog te undisablen.
Maar beter nog is helemaal niet naar deze waarde te kijken, maar gewoon in je script te bedenken wat de waarde zou moeten zijn. User-input is immers nooit te vertrouwen.
Omdat er eerst wat anders gewijzigd moet worden voordat deze gewijzigd mag worden. En door die checkbox wel te tonen ontstaat er consistentie in de gui.quote:
Waarom heb je uberhaupt de waarde van een checkbox nodig als je hem niet kunt wijzigen?
Lijkt wat zinloos...
Maar je weet of deze gewijzigd mag worden of niet. In je logica weer je dan toch ook of hij gewijzigd mag worden of niet? En als hij niet gewijzigd mag worden (en dus disabled is) heb je de value dus helemaal niet nodig?
Of mis ik nou echt iets?
Anyway, hulde voor de consistente gui
Ik heb er echt een grafhekel aan als dingen verspringen als ik ergens op klik...
Of mis ik nou echt iets?
Anyway, hulde voor de consistente gui
Ik heb er echt een grafhekel aan als dingen verspringen als ik ergens op klik...
Het is een edit van een bestaand product. Ik had in de verwerking kunnen controleren of 'details' al gezet is, of ik kan de value simpelweg meegeven in het form om te zorgen dat hij 'details' niet update.quote:
Maar je weet of deze gewijzigd mag worden of niet. In je logica weer je dan toch ook of hij gewijzigd mag worden of niet? En als hij niet gewijzigd mag worden (en dus disabled is) heb je de value dus helemaal niet nodig?
Of mis ik nou echt iets?
Anyway, hulde voor de consistente gui
Ik heb er echt een grafhekel aan als dingen verspringen als ik ergens op klik...
Ik heb nu voor het laatste gekozen omdat ik anders nogal wat kunst en vliegwerk in bestaande code moest gaan toepassen.
hmmm, ik weet natuurlijk niet hoe je script eruit ziet, maar op zich lijkt een ifje om de waarde die de checkbox enabled/disabled voldoende?
Anyway, je zet nu een hidden veld als hij disabled is, en die haal je weer weg als je hem enabled ofzo? Als je hem niet weg haalt zouden de checkbox en het hidden veld elkaar wel eens dwars kunnen zitten namelijk...
Anyway, je zet nu een hidden veld als hij disabled is, en die haal je weer weg als je hem enabled ofzo? Als je hem niet weg haalt zouden de checkbox en het hidden veld elkaar wel eens dwars kunnen zitten namelijk...
Dat had voldoende geweest als er geen andere stuk code was wat nog wat met die 'details' deed.quote:
hmmm, ik weet natuurlijk niet hoe je script eruit ziet, maar op zich lijkt een ifje om de waarde die de checkbox enabled/disabled voldoende? :)
Uiteraardquote:Anyway, je zet nu een hidden veld als hij disabled is, en die haal je weer weg als je hem enabled ofzo? Als je hem niet weg haalt zouden de checkbox en het hidden veld elkaar wel eens dwars kunnen zitten namelijk...
| 1 2 3 4 5 | if($edit_details==1){ echo'<input type="hidden" name="details" value="1" /><input type="checkbox" name="bogey" value="" checked="checked" disabled="disabled" />'; }else{ echo'<input type="checkbox" name="details" value="1" onclick="toggle(\'details\')" />'; } ?> |
Hoe kan je een 'secure' login systeem bouwen met cookies? Want cookies zijn zo over te nemen. Enkel checken op IP zal niet voldoende zijn lijkt me?
ne okuyon, bokmu var?
Alles via SSL doen, op IP en useragent locken, en je sessie ID steeds vernieuwen (zoals cakephp met security op high het doet) veel meer kan je niet doen?quote:
Hoe kan je een 'secure' login systeem bouwen met cookies? Want cookies zijn zo over te nemen. Enkel checken op IP zal niet voldoende zijn lijkt me?
phluphy for president!
Wat bedoel je met secure?
Je userdata hoef je niet in een cookie te zetten natuurlijk... Als je de cookie gebruikt om automatisch in te loggen hebben je sowieso een ontzettend security risk (iedereen die die pc gebruikt is automatisch ingelogd).
Je userdata hoef je niet in een cookie te zetten natuurlijk... Als je de cookie gebruikt om automatisch in te loggen hebben je sowieso een ontzettend security risk (iedereen die die pc gebruikt is automatisch ingelogd).
Kuch, als je een generic account gebruikt misschien, maar mijn chick is echt niet ingelogd onder mijn user op fok op onze gezamelijke PC.quote:Op maandag 24 november 2008 16:25 schreef Xcalibur het volgende:
Wat bedoel je met secure?
Je userdata hoef je niet in een cookie te zetten natuurlijk... Als je de cookie gebruikt om automatisch in te loggen hebben je sowieso een ontzettend security risk (iedereen die die pc gebruikt is automatisch ingelogd).
En flikker je Fok cookie eens weg en kijk of je nog steeds ingelogd bent.. Talking about cookies en automagisch inloggen
In theory there is no difference between theory and practice. In practice there is.
Dat ieder die achter die pc zit direct ook automatisch ingelogd is is logisch, de app kan natuurlijk niet zien wie er daadwerkelijk achter de pc zit.quote:Op maandag 24 november 2008 16:25 schreef Xcalibur het volgende:
Wat bedoel je met secure?
Je userdata hoef je niet in een cookie te zetten natuurlijk... Als je de cookie gebruikt om automatisch in te loggen hebben je sowieso een ontzettend security risk (iedereen die die pc gebruikt is automatisch ingelogd).
Ik wil een login systeem bouwen op basis van cookies, echter dit zo veilig mogelijk.
ne okuyon, bokmu var?
. Maar nu kan ik nergens een lekker script vinden. Het moet een 'partyagenda' worden. Dus elke vrijdag/zaterdag. Iemand een tip?
