I think your lack of atomicity is going to get you into trouble, though if you have a low traffic environment it won't happen often, and when it does you'll be quite perplexed. The problem will be when one process (we'll call it "process A") makes an insert, then another process ("process B") makes an insert, and then process A checks the last insert ID, getting back the insert ID for process B's operation, and not its own. This may in fact never happen if your environment isn't being hammered on too heavily, but if it does happen, it will result in a bug that will be very hard to reproduce.

To be absolutely safe, you need either a database mechanism that both inserts and gets the insert ID atomically (you can do this with DBI as Bart suggests, but I don't know about your wrapper), or you need to generate your own insert ID randomly, try inserting into the table with it, and also do exception handling for the rare scenario of a collision, in which case you'll want to generate another id and try again.