I was puzzled by your socket connection sub. First, either you aren't using strict, or else there's a (global?) declaration for the variable "$return" that you aren't showing. Second, you do a "return $return;" followed by an "if(...)" -- and of course the "if" statement can never be reached.

That might not have anything to do with your problem, but if you add "use strict;" and clean things up, the real problem might be revealed. BTW, I notice that the "doSQL" sub refers to $usingDB, which not passed to or declared within the sub. This is generally considered poor form. It's better for the sub to be fully self-contained, not referring to any globals outside its own scope. (And anyway, if $usingDB is false, this sub shouldn't have been called in the first place.)

As for database performance, perhaps you can figure out a way to use a consistent sql statement with placeholders, such that a given statement only needs to be prepared once per run connection (I presume there's one connection per run). Something like this:

sub doSQL
{
    my ( $tablename, $fldnames, $fldvals ) = @_;  # change call params
+:
           # string, array_ref, array_ref

    my $sqlstring = "insert into $tablename (", join( ',', @$fldnames 
+) .
        ') values (' . join( ',', ('?') x scalar @$fieldnames ) . ')';

    my $sth = $dbh->prepare_cached( $sqlstring );
    $sth->execute( @$fldvals );

    # add error checking as desired...
}
[download]

(updated to fix a misspelled variable name)

You'll probably want to read the section in the DBI manual about the "prepare_cached" function.