http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10478
--- Comment #5 from M. Tompsett <[email protected]> --- I was playing with DBI's last_insert_id and I'm generally impressed. I can't seem to trick it into giving me results I don't want. Even in threaded and forked code, because the database connection handle is different, last_insert_id returned the last_insert_id of the process or thread I was expecting. So, even a split command which uses DBI's last_insert_id is okay, in my assessment. You can see what I mean by a split command (INSERT and last_insert_id separated) in my patch on 10454. While simplifying my patch (see bug 10454), I realized that the complexity of a Process_ID (to uniquely ID which process/thread is running this) I had aided me in preventing gaps created by some forms of mistakes (hitting refresh while adding patron a couple times). However, I have posted my simplified code, which is subject to huge fake gaps (keep hitting that refresh on a patron entry screen). Overall, this isn't really just a sequential number problem (let's just +1), it's a sequential STRING problem. If you looked at my patch, I actually calculate my_UID (because I add a blank cardnumber to be filled in and grab last_insert_id), calculate all the cardnumbers which haven't been calculated yet (effectively $currentvalue = nextvalue($previousvalue) then updating the UID record being calculated), and once everything is calculated, I grab my value using my_UID. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
