in reply to loop not ending...

Your dienice() doesn't actually print anything, it returns a string, but you're not using the return value in any way...

Is there a reason you're connecting to a database in every iteration of your loop? That's probably going to be slow. Is there a live database connection at the beginning of the loop? Prepare all your SQL statements OUTSIDE of the loop with separate statement handles, and just execute them INSIDE the loop. Except for the CLASSES_RECORD insert statement, then maybe you could use 'prepare_cached'...

You CAN use placeholders/bind values ('?') even in the insert statements, you know.

Also, set RaiseError at least while testing. See 'perldoc DBI'.

And last, have you tried running it in the debugger?

Replies are listed 'Best First'.
RE: RE: loop not ending...
by jptxs (Curate) on Oct 25, 2000 at 01:13 UTC

    actually, the DB connection code and everything in that block had originally been in a module of my own. I ended up bringing it back into the main program for debugging so I can watch them interact. I did put the connection in the wrong place when i did so...but speed is far from my concern at the moment. there will never be more than two to five statement to go through, so i sacrifice the prepare for having them all together.

    as for RaiseError, I just prefer to test the results of each operation. Id o this so that things like disconnects or finishes that go wrong don't end up tripping up the rest of the program.

    "sometimes when you make a request for the head you don't
    want the big, fat body...don't you go snickering."
                                             -- Nathan Torkington UoP2K a.k.a gnat

[reply]
      Not to be too nitpicky, but if your code is going to hang as a result of a failed DBI call, then it's never going to get the chance to be tested. I haven't actually looked at the internals of DBI (hold on while I put on my asbestos suit), but I would imagine that there is a sub DESTROY that will clean up after a messy exit. On the converse, if RaiseError is set and the DBI calls are safe, you're not going to ever encounter the issue anyway.

      If I ever have a piece of code that is giving me a DBI related problem, first thing I do is set RaiseError. <shrug>

      ALL HAIL BRAK!!!

[reply]
[d/l]
      I say use placeholders and prepare once whether or not your statements get executed once or a hundred times, not necessarily for performance reasons, but just because its 'the right thing to do(tm)'. You don't have to worry about quoting your values correctly, the database itself might be able to cache the statement, thereby saving some database load if anyone else runs the same statement and/or the same script, and I know of one database that used to have a bug where if the same statement was prepared over and over too many times, it just didn't get prepared successfully anymore (now that was a hard bug to find).

      Ok, if the database is MySQL, then there's no real performance gain, but at least the code is more ready for another database that does benefit from such things. At least use prepare_cached w/placeholders if you can, which is the 'easy way' to prepare once.

      And what PsychoSpunk says above about RaiseError.
[reply]

In Section Seekers of Perl Wisdom