in reply to dbi update statement is very slow
Have you actually checked the connect statement for errors? It seems quite likely that the program is telling the truth, and the server cannot be found. Do you have any other DBI using scripts running from this server?
--
Tommy
Too stupid to live.
Too stubborn to die.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: dbi update statement is very slow
by ctaustin (Sexton) on Aug 14, 2002 at 16:17 UTC | |
Database: Oracle (8.1.7.3) I am not performing a commit after the initial data load because I am inserting into a transaction level temporary table so a commit will delete the data. We have several DBI scripts that make calls to various oracle database, this specific instance included, so I know that everything works. Here is the sub routine that is doing the work:
Thanks. | [reply] [d/l] |
by tommyw (Hermit) on Aug 15, 2002 at 12:00 UTC | |
Found it! First, clean up all the preamble: The while loop at the top can be rewritten as: 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:
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. -- | [reply] [d/l] [select] |