• Hanzito (unregistered)

    Actually worse than failure. Had the statement failed, it probably would have been noticed sooner.

  • Darren (unregistered)

    Ah, the old "well we've checked absolute nothing but we're 1000% sure the problem isn't at our side - if you think it is, prove it!" response from suppliers. An annoyance I think we all know too well.

    Once tried to tell a local council that one of their connections was down (which they should have already known as all their data was now going over one connection rather than being balanced over two!). They refused to believe us. Ended up with us, two ISPs, two MSPs and the national telecoms provided telling them before they'd entertain the idea of beginning to think about the possibility of looking into it.

  • (nodebb)

    Yep, good reason why writing your own SQL is never a good idea and like JavaScript it should be generated. I'm pretty sure who ever wrote that added the FROM clause out of habit.

  • Foo AKA Fooo (unregistered)

    In an ideal^Wsomewhat reasonable world, you would just threaten to sue them for gross neglect with a copy of the bill attached, and watch how quickly they resolve the issue, but of course, we're long past living in a somewhat reasonable world ...

  • (nodebb)

    I wonder if the dev who wrote that SQL statement was an Oracle user? I only think this because the FROM part of the statement is REQUIRED, and Oracle has a dual table for the sole purpose when you don't need data from a table.

    Addendum 2025-09-23 08:58: I just remembered why they may have thought to use the FROM part: they might think that the last_insert_id() will look at the FROM statement and use the id from that table, and not just the last generated id from all tables.

  • (nodebb)

    They app was built, tested, and released, and everyone was happy. Everyone was happy until the first bills came in.

    "Everyone" apparently did not include the non-existent people who monitored database activity. How do you start a new application and not monitor database activity?

  • Tinkle (unregistered)

    Please tell me that last_insert_id() is transaction specific.

    It sounds like a race condition bug waiting to happen.

    Hmm, first result on Googling suggests using an OUTPUT clause. Or is this a 'how to say you do not SQL without saying you do not SQL'.

  • (nodebb) in reply to Tinkle

    From: https://dev.mysql.com/doc/refman/8.4/en/information-functions.html#function_last-insert-id

    The ID that was generated is maintained in the server on a per-connection basis.

  • JustaDBA (unregistered) in reply to Tinkle

    MySQL is a separate beast. Your answer is correct for SQL Server.

  • (nodebb) in reply to Tinkle

    The equivalent gets "fun" in SQL Server... https://stackoverflow.com/questions/1920558/what-is-the-difference-between-scope-identity-identity-identity-and-ide

  • Álvaro González (github) in reply to Tinkle

    Please tell me that last_insert_id() is transaction specific.

    It's connection specific, you don't even need to start a transaction. MySQL was created with many quirks but this feature was right from the beginning. Failing to use it properly can only be explained by the fact that some kind of developers go through their entire career trying to learn the least they need to do their job.

  • John (unregistered)

    I don't get it. Must be something specific to MySQL.

  • OldCoder (unregistered) in reply to dpm

    You must be new here.

  • (nodebb) in reply to OldCoder

    You must be new here.

    . . . or hopelessly optimistic.

  • (nodebb) in reply to OldCoder

    I can see how this happened: Internal non-IT customer buys product+service, but do not leave budget for internal IT to keep an eye on services. Or even tell internal IT of purchase.

  • (nodebb) in reply to Darren

    Ah, the old "well we've checked absolute nothing but we're 1000% sure the problem isn't at our side

    I think it's more likely a case of "we ran it on our 10Gbps LAN with the two machines located right next to each other and didn't find any problems, so it must be at your end". There's at least one international standard that was developed that way, the company that paid for it apparently never tested it outside their own LAN so when it was deployed on the Internet where you have nasty things like, for example, packet loss, it was found not to work.

  • (nodebb)

    They had a MySQL database hosted on Cloud Provider A. They hired a web development company, which wanted to host their website on Cloud Provider B. Someone said, "Yeah, this makes sense," and wrote the web dev company a sizable check.

    The third sentence, starting with the word "Someone", is TRWTF in this. In what universe does it make sense to run the database in one provider and the website in another?

    Or have I missed something horribly obvious somewhere?

  • Mike Guest (unregistered) in reply to Steve_The_Cynic

    That was my thought as well. "Someone" should have just said NO.

  • eluvatar (unregistered)

    I'm kinda surprised that the connection between the database and application has no form of compression. I suppose that's unlikely to be useful is most cases but it would be interesting.

Leave a comment on “One Last ID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article