use strict;
my @to_insert = (
        { 'A' => 1, 'B' => 1 },
        { 'B' => 2 },
        { 'A' => 3 },
);

for my $row (@to_insert) {
        my $insertStmt;
        my $cols;
        my $vals;
        for my $col (keys %{$row} ) {
                $cols .= $col . ",";
                $vals .=  "?,";
        }
        $insertStmt = "insert into blah ($cols) values ($vals);";
        print "$insertStmt\n";

}
[download]

sub inserter
{
    my ($tablename, @insert) = @_;

    my $sql = "INSERT into $tablename SET";

    my $rows_affected = 0;
    foreach my $insert (@insert)
    {
        my @columns;
        while (my ($k, $v) = each %$insert)
        {
            push @columns, "$k = $v";
        }

        $rows_affected += $dbh->do(
            $sql .
            join(',', @columns),
        ) || die $DBI::errstr;
    }

    return $rows_affected;
}
[download]

That should do most of what we want.

Liz

Yes in fact it seems to be effectively the same. I hadnt found that thread in my poking around here. :(

In regard to Jenda's solution, it sounds specific to UPDATE queries. Any idea what'll happen on an insert query? I suppose i could just try it out myself!

Thanks much!

You could use COALESCE just as well on INSERT. Something like:

INSERT INTO table (id,type) VALUES (
 id,
 COALESCE(?,defaulttypevalue)
)
[download]

Well, in general if a field is given the NULL value (which will be inserted if the given value for a placeholder is undef), then the database decides what to do with it. Usually it will just be marked as NULL in the database (as in: not having any value). Sometimes you can specify a default value when you create the table. Sometimes something special happens (e.g. with a TIMESTAMP field in MySQL).

Liz

and was answered by Jenda?

I was under the impression that many wise monks answered your question. Jenda's solution is just one of the many you got.

The answers of the wise monks, apart from Jenda's answer which introduced COALESCE() to me, all involved creating the query on the fly, over and over again. This is something that I have been doing since basically 1995, so that didn't bring much news to me.

In my opinion, Jenda's answer was the only one that addressed the fixedness of the statement handle for the update. And therefore was considered an avenue for me to go in. And also in this thread, the only new answer for shemp as far as I can see.

MySQL 4.1 seems to support prepared statements on the server side. Too bad DBD::mysql doesn't support that yet. Any takers? ;-)

Liz

If a column can accept a null value and you dont assign a bind value to it, thats ok, a null is inserted there. But for non-null columns that arent assigned a bind value, an error like this occurs: (for MySQL at least)

DBD::mysql::st execute failed: Column 'blah' cannot be null at bind_test.pl line 32.

Yes this is probably well-documented somewhere, but i thought i had read quite a lot of bind param documentation, and much more was learned in working on this problem.

*** Note: I have only tested this for char and int type columns, im assuming that other columns will behave similarly. (assuming will bite me though - as it always does)

#set your defaults for the table in question
my %defaults = ('col1'=>'col1_default_value','col2'=>'col2_default_val
+ue'...);#you get the idea.

#your data set
my @to_insert = (
      { 'A' => 1, 'B' => 1 },
      { 'B' => 2 },
      { 'A' => 3 },
);

#clean it up for the statement handle
foreach my $rec (@to_insert){##each record to be inserted
    foreach my $key (keys %defaults){##each field in the record
        unless(defined $rec->{$key}){
            $rec->{$key} = $defaults{$key};
        }
    }
}
[download]