in reply to prepare_cached for DBI::Oracle
Start with Super Search and look for prepare_cached.
--
Brovnik
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Re: prepare_cached for DBI::Oracle
by Anonymous Monk on Jun 22, 2001 at 15:02 UTC | |
| [reply] [d/l] |
by Anonymous Monk on Jun 22, 2001 at 15:57 UTC | |
My head is certainly not working well today (o: Ok, to be simplier. I just put the relevant info here. Both SQL statement are prepared_cached, but only the second one is working... I also tried to add code to track down error message, but nothing is returned )o; I bet the solution is silly as hell, but I can't find it... maybe need some rest (o;{{
| [reply] [d/l] |
by Arguile (Hermit) on Jun 22, 2001 at 16:36 UTC | |
DBI->trace() is your friend and so is $sth->errstr. First up is $sth->errstr who you really should be using after all your prepare and execute statements like this:
DBI->trace() is more a development tool, it has multiple levels of tracing for very effecient debugging.
The DBI->trace(2, 'tracefile') takes one or two parameters, the first is the trace level as illustrated above, the second is an optional file to dump the debugging log into. I'm recalling this out of Programming the Perl DBI which is an excellent book, but it's on loan to a friend so I hope the table's correct. I was/am preparing a more detailed post given some of your other code (Oracle DBA here, so this stuff is fun for me) but I'm pretty busy so I thought I'd just share this until I get a few moments Update: Added the $sth->errstr() stuff then noticed it had already been mentioned by andye Update 2: Have a few more moments, I'd really like to go over your general query structure but that would take more time than I currently have so let's stick to some little things (BTW brovnick covered a really good point, personally I see $count as very perplexing given you can just iterate over the cursor):
Notice the single quotes around __EOSQL__? By default here docs are interpolated, you don't want perl to spend the time checking and you certainly don't want it interpolating in this case. So explicitly state it as shown. Also, if you want, you can use table aliases. I handle a lot of queries a day and it's so much faster to type and easier to read when they're used (check the FROM clause to see how it's done).
Using a fetched reference instead of an array is much faster and uses less memory, b/c each time your cursor moves (ie. iterate to the next record) DBI uses the same memory space instead of creating a new array. This would necesitate some major changes to your structure, but if you want more speed you'll probably be doing them anyways. The hash reference is a bit slower on lookup simply b/c it is a hash, however, the benefits of it should be obvious. Now $rec actually means something instead of being just a number. P.S. Consider joining, it's painless: It's also much nicer talking to a name than Anonymous Monk | [reply] [d/l] [select] |
by Eric.D (Initiate) on Jun 22, 2001 at 18:01 UTC | |
by andye (Curate) on Jun 22, 2001 at 16:57 UTC | |
andy. | [reply] [d/l] [select] |
by Brovnik (Hermit) on Jun 22, 2001 at 17:11 UTC | |
(Apologies if this is teaching you to suck eggs) 1. If your main concern is overall speed, I suggest some detailed profiling. Find where the code is spending most of its time. See Benchmark. Use the Benchmark->new and timediff() methods to look at checkpoints. Since you are doing lots of logging anyway, have your loggit() call put a timestamp in the LOG.
2. Have you turned on the error checking in the DB ? in the connect(). It could be that there is a problem in the prepare() line. 3. Is it only failing if you use prepare_cached ? I.E. does it work without the _cached ? 4. Are you using the $sth->finish() when no longer needed ? This can generate errors if there is an open execute and _cached is called again.
That's all I can think of right now, good luck.
| [reply] [d/l] |
by Eric.D (Initiate) on Jun 22, 2001 at 17:34 UTC | |
by Arguile (Hermit) on Jun 22, 2001 at 17:46 UTC | |
by Brovnik (Hermit) on Jun 22, 2001 at 18:39 UTC | |
by Eric.D (Initiate) on Jun 22, 2001 at 18:32 UTC | |
Re: Re: prepare_cached for DBI::Oracle
by pope (Friar) on Jun 22, 2001 at 16:05 UTC | |
I followed your suggestion and... Super Search took me back to this thread! :-D | [reply] |
by Anonymous Monk on Jun 22, 2001 at 16:19 UTC | |
There is the threat : Code useless, forget it... this is more usefull (o; by Anonymous Monk on Jun 22, 2001 at 11:57 which give the piece of code which troubles me... Eric. | [reply] |