"I have tried a number of joins and mappings to make this all come out right, but it's nearly impossible to stuff all the values into the right order when the statement can vary drastically from one run to another."

Nonesense. ;)

Say you have a hash ref like so:

my $hash = {
   name  => 'Joe',
   phone => 222,
   code  => 'A',
};
[download]

Just a simple hash ref whose keys are fields in a database table. Now consider this sub that takes two args, a scalar (the name of the table to insert into) and a hash ref:

sub insert {
   my ($table,$hash) = @_;
   my $sth = $dbh->prepare(
      "insert into $table ("
      . join(',', keys %$hash)
      . ') values ('
      . join(',',map '?',keys %$hash)
      . ')'
   );
   $sth->execute(values %$hash);
}
[download]

What's so impossible about that? Of course, you don't have to use a hash ref, you could use a hash - or two arrays, or two array refs. The important thing is that key 3 always points at value 3 - order doesn't matter, and that's why i prefer a hash for this.

If your queries are still too complex for this, then i recommend you look into SQL abstraction modules such as DBI::Wrap or DBIx::Abstract.

Also, i only use do() for quick-n-dirty stuff. From the docs:

The do() method can be used for non repeated non-SELECT statement
(or with drivers that don't support placeholders) ...

Best to stick with prepare, but note that if every query is going to be significantly different (different columns, different tables), then you won't gain much from prepare's caching.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)