in reply to Re: Re: dbi update statement is very slow
in thread dbi update statement is very slow

Found it!

First, clean up all the preamble: The while loop at the top can be rewritten as:

open (FILE,$dir) || &error("Can't open $dir: $!"); $sth=$dbh->prepare("insert into convert.sql_edits values (?, ?)"); while (<FILE>) { chomp; ($id, $value)=split/\|/; $sth->execute($id, $value); push @total, $sth->rows; } $sth->finish; close FILE;
since you're not using any of the values read (other than via the database).

The subsequent SQL statement building can be simplified, since you're using $type and $field to determine the table name, and the rest of the SQL statement doesn't vary.

And having cleaned sheer volume of setup out of the way, and thus determined that it can't possibly be the cause of the problem, the only part left is:

$sth=$dbh->do($sql) || &error("Unable to perform update statement:<br /><br />$sql<br />< +br />$DBI::errstr\n"); $updated=$sth->rows; $dbh->commit() || &error("Unable to commit changes made by the update statement: <b +r /><br />$sql<br /><br />$DBI::errstr\n");; $sth->finish;

But the documentation says the $dbh->do returns a row count, not a statement handle. So there you go.

Finally, why bother with the convert.sql_edits table anyway? For every record in the table being updated, get the counter value, look it up in @edits, and set the appropriate field. That'd probably save a lot of grief: you'd have one database call per record updated, rather than one per convert line, which may or may not be better, but they wouldn't all have to be deleted afterward, either.

--
Tommy
Too stupid to live.
Too stubborn to die.