I feel like poor Paco.

I fully understand the value of storedProcs, and the value of abstracting, and the value of not using SQLs in the scripts, etc. I merely wanted to find out how to replicate a multi-command SQL proc in my script, because, well..., because I wanted to.

I have come to the conclusion that it is messy to do so because DBI doesn't seem to provide the ability of abstracting the transactions for me, but that is a good and valuable conclusion.

Now, I have a minor quibble to pick with the above post.

Besides from the reasons given by other people, it gives database people the opportunity to re-organize the data layout (add/delete columns, split tables) without having to modify an unknown number of programs - all that's needed is to change the relevant stored procedures.

Well, what the heck are storeprocs other than an "unknown number of programs?" I can't see how the db structure can be changed, and yet storedProcs can prevent any pain? Whether I get to the data via a SQL statement in my Perl script, or via a storedProc in the database called from my Perl script, somewhere, someone will have to change something.

I think the dba types tend to think one way only -- that the world depends on the database they are custodians of. While that may be true in their realm, there are tons of small programs and processes that are run using databases where the dba can't do everything. The programmer has to find ways to do things in a variety of ways.

That is the kind of situation I ran into.

Anyway, thanks everyone for the input. Every bit helps.