This is not a bug
At least not on your code. It is a bug in your process. Your project manager should be a lot more worried about your process than your code.
How do you deal with this?
Quite simply, by not letting engineers change production or shared development databases.
Assuming this is a shared development database:
Ideally, if at all possible, avoid having a shared database in the first place. Instead, have per-developer databases that are short-lived. This should be automated with scripts, otherwise the cost to test becomes too great, and there's a incentive to not test things. You can have these databases on either the developer's workstation, or on a central server.
If, for some reason, you absolutely MUST have a shared database, you should use fixtures - essentially, something that sets the database to a known-good state every time you need to use it. This avoids developers getting bitten by other people's changes.
If you need to apply permanent changes to the database, you should commit them to your source control. Setup your database such that devs don't have permission to write to it directly, and have a program that pulls changes from source control and applies them.
Finally, from your description on how you're debugging things, it sounds like you're not using CI. Use CI. It's a bit of a pain to setup, but it'll save SO much time in the long run, not to mention stop you from worrying about unreproducible database bugs. You'll only have to worry about heisenbugs now!
Assuming this is a production database:
If your devs are changing production databases, many things have gone horribly wrong, even if the changes are absolutely correct.
Developers should never access production databases. There's absolutely no reason to, and so many things that can go very very wrong.
If you need to fix something in a production database, first you backup, restore that backup on a different (development) instance, and then play around that development database. Once you think you have a fix ready (on source control!), you re-do the restore, apply the fix, and see the result.
Then, after backing things up again (and ideally preventing concurrent updates), you fix the production instance, ideally through a software patch.
If you need to test something in a production database... no, you don't. Whatever tests you need to do, you should do in a development instance. If you need some data to do the tests, you get that data in there.