Far saner would be to try to move things towards two basic design ideas.

The first is transactions. Create a temporary space. Try to do work. If work succeeds then commit the transaction (ie copy from working to live), if it fails rollback (ie drop the temporary space), with appropriate locking if need be. Databases make this easy. You can do it, less reliably and with more work, with filesystems. It will help you avoid disentangling messes.

The second is keeping track of state somewhere. Have a simple table that registers a ton of jobs and their state. Every major step, mark the work as needing to be done, try to do it (with usual error handling, dying if something goes wrong, etc), and then if it succeeds mark it as having been done and mark the next thing as needing to happen.

That strategy results in code that (in my experience) will recover cleanly from most unexpected problems. Combine the two, and if a step has a problem you get notification, further damage is not done, and you are then left knowing which step went wrong and with the ability to investigate that one at your leisure. And then you can leave completing it for the next night when the process runs again.

Trust me on this. While a band-aid may be doable and may assist with your immediate situation, even incremental steps towards a saner architecture (like above) will make your life much better.

And, of course, try to create testing environments, use revision control, all of the usual good stuff...

Lol ++ for having the same ideas as me :)

We have a alpha, beta and production environment. I'm busy implementing CVS.

But fact is I'm taking over existing code here. Now I have to iron out the bugs. But the code is already in production. What happens is that now and then I get wrong data due to bugs in the code. Then I need to make that data correct manually.

Fact is due to historically redens I'm stuck in this situation that need to be solved:

a. by solving the bugs how this happens
b. make the corrupt data correct

But by what I want is to narrow down where things go wrong by:

a. logging every good step
b. try to log where something goes wrong


--
My opinions may have changed,
but not the fact that I am right

Depending on how cool your database is, I found the technique of having all SQL UPDATE statements dumping the original and new values incredibly useful.

I guess that you can get far with clever tieing of filehandles and database handles to catch many updates, but other than grepping for the "relevant" statements and wrapping them with some errorchecking, I see no bulletproof way of making your code more accessible...