De grote nationale probeer-de-Steenderen.NET-database-op-te-blazen actie is afgerond (wat een fantastische scabbelwoord overigens weer, maar dat geheel terzijde). Na meer dan 100.000 fout getypte codes door SPAM-koningen, die blijkbaar toch niet zo koning blijken te zijn als een echte koning, heeft de database zich netjes geweerd.
Vreemste gewaarwoording, waar ik wel een work-around voor geknutseld heb, maar nog geen logisch antwoord op de vraag heb is een verschil in data wanneer ik info uit de basebase lees. Om precies te zijn (heb je geen zin in een technisch verhaal, haak dan nu af!) per nieuwe entree in de log tabel, werd eerst de laatste entree achterhaald met een simpele: “SELECT MAX(id) FROM logbook”.
Tot zover weinig ingewikkelds, maar wanneer dit commando wordt uitgevoerd vanaf de webserver in de ASP code, dan kan het voorkomen, maar natuurlijk ook weer niet altijd, dat daar een andere waarde uitkomt, dan wanneer deze SQL wordt uitgevoerd via een directe MySQL client verbinding naar de database.
Om precies te zijn, komt er via de webserver zo nu en dan niet de laatste entree uit, maar ééntje daarvoor. Dan dat werkt dus niet zo lekker, want daardoor heb je de neiging om een nieuwe entree in te schieten, met een id dat dus al bestaat. Gevolg, une crash de script, of zoiets.
Oplossing is een eenvoudige, id voor het logbook mag best een auto-incrementing waarde zijn. Maar dat verklaart nog niet hoe deze vreemde mis-match ontstaat… laat staat waarom dit verschijnsel soms wel en soms niet ontstaat.
