in reply to Re^4: Problem Running More than Two Successive (I think) Sql SELECT statements, DBI, DBD::Oracle
in thread RESOLVED - Problem Running More than Two Successive (I think) Sql SELECT statements, DBI, DBD::Oracle
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^6: Problem Running More than Two Successive (I think) Sql SELECT statements, DBI, DBD::Oracle
by perldigious (Priest) on Feb 07, 2020 at 22:06 UTC | |
I've actually already tried it with and without them, and I have completely removed them now. The original code I wrote when I started down this adventure didn't have them, I added them later to try and fix the issues I was seeing. The official DBI docs recommend against them unless you know you are only retrieving a part of the data set you queried. Another of my Oracle DBAs was actually very helpful and switched me to a different service and tweaked some other options in my connection string a bit. Now it's a lot more stable, albeit seemingly a bit slower for both connect/disconnect and data retrieval. I'm still doing the silly repeated disconnect/reconnect with some long waits, but now the worst I've seen is the occasional error thrown that says:
But it's rare, and I can probably just write some error handling/retry x times code around it and make it reliable enough for my purposes. Once again, and mostly just for posterity's sake (and my own, but hey, someone else may find it useful), I'll provide the full script, SQL, and sanitized tnsnames.ora file as I currently have them set since it seems to be mostly working (famous last words, probably regret them shortly) now.
Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.
| [reply] [d/l] [select] |
by Marshall (Canon) on Feb 08, 2020 at 23:58 UTC | |
Why this?: I read the following:
connect_cached is like connect, except that the database handle returned is also stored in a hash associated with the given parameters. If another call is made to connect_cached with the same parameter values, then the corresponding cached $dbh will be returned if it is still valid. The cached database handle is replaced with a new connection if it has been disconnected or if the ping method fails.I don't see any need to drop your db connection and then re-connect. I recommend to ditch this connect_cached method. Connect once without caching and stay connected. There could be some glitch with this connect_cached method that is screwing things up? Stuff like "but it can also cause problems and should be used with care." are red flags to me. | [reply] [d/l] [select] |
by perldigious (Priest) on Feb 10, 2020 at 14:30 UTC | |
Oh, I'm not a big fan of how I'm doing this either. For me it's a kludge that seems to fix another problem I had with this. So are the all the connect/disconnects, I had another different problem without them. I had also tried adding finish method calls instead with no luck. I'm not savvy enough at this stuff to be that effective on debugging, but I know if I do go back to just a single connect that isn't cached and/or remove the explicit disconnects I still see the issues. I'm sort of relying on my Oracle DBAs at this point, and since one of them switched the service I connected to and added a few other connection options things seem far more stable than they have ever been previously. I'm still holding out hope I can figure out what's really going on as I work with my employer's database from Perl more, but for now I'm way behind at work and I have to let this one go.
Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.
| [reply] [d/l] |
by Marshall (Canon) on Feb 10, 2020 at 16:53 UTC |