I think that you should be checking the value of DBI::err or the equivalent property of a handle.

Sounds funny but, what I usually do is to “try something that I know is right,” and then “something that I know is wrong,” and observe what actually happens in both cases.

In addition, I strongly suggest that you use query parameters, and not simply as a defense against SQL injection.   You prepare the query once, and execute it as many times as necessary, binding a different value to the parameter each time.   (Both execute and do have arguments expressly designed for this.)

Take explicit control of your database transaction behavior.   Issue begin_work and commit/rollback calls explicitly.   Observe what the application is actually doing in response to the source-code you have written.

I have become a big fan of the various Test suites, and of the notion of creating regression tests for every module that I write, as I write them.   The modest additional effort is worth every single penny when debugging, and it greatly reduces the amount of “debugging” that you actually have to do.   Just last week, I “whipped out a little module,” briefly thought to myself that it really didn’t require a test suite ... wrote one anyway, and heh ... every one of the methods that I had just written had a subtle bug in it.