You can disable DBI from raising exceptions on errors. The error message might be helpful (if there is one).

$dbh->{RaiseError} = 0 ; # don't raise exception on error
$dbh->{PrintError} = 1 ; # print errors to console

$cursor->execute($region_id) or warn $DBI::errstr, "\n" ;
[download]

Thanks - I will incorporate that...

Thank you - that's an excellent lead. I'll give the $dbh->selectall_arrayref a shot.

Re: the placeholder - thanks for the catch, but I had been too sloppy in editing the original code. There is indeed a placeholder:

my $sql_region_id = "select distinct k.id 
        from config.object o 
        join config.location l on l.id=o.location 
        join config.location k on k.id=l.region
        order by k.id desc";

my $sql_statement = "select
x.ip,
m.modemmacaddress,
m.date_time,
m.cmtsrxsnr,
m.cmtsrxpower,
m.modemrxsnr,
m.modemrxpower,
m.modemtxpower,
m.microreflections,
m.corrected,
m.uncorrectable,
a.node,
a.addr,
a.street,
a.city,
a.state,
a.zip5,
k.name,
i.ifDescr

from config.object o

join config.location l on l.id = o.location
join config.location k on k.id = l.region and k.id = ?
join nemos.arp x on o.id = x.object
join modem_hist.mh_day_0  m on m.cmtsid = x.object and m.modemmacaddre
+ss = x.mac
join cust.equipment e on e.mac = x.mac
join cust.addr a on a.acct = e.acct
join config.ifdrum i on i.object=o.id and i.ifdrum = x.ifdrum

where o.community is not null and i.ifindex > 0 and  
(m.modemtxpower < -15 or m.modemtxpower > 55)
or (m.modemrxsnr < 28)
or (m.modemrxpower < -12 or m.modemrxpower > 12)
or (m.cmtsrxsnr < 25)
or (m.microreflections > 40)
";

unless ( $region_cursor = $dbh->prepare( "$sql_region_id" )){
   exit 1;
}

unless ( $region_cursor->execute ) {
   exit 2;
}

$region_cursor->bind_columns(\($region_id));

while( $region_cursor->fetch() ){

   unless ( $cursor = $dbh->prepare( "$sql_statement" )) {
        exit 1;
   }

   unless ( $cursor->execute($region_id) ) {
          exit 2;
   }
   
   while( $cursor->fetch() ) {
        do stuff...
    }
}
[download]

I do not find it to be the case, i.e. categorically, that “you can’t execute another query while you are fetching the results of an earlier one.”   (In fact, I just did it.)   As long as you are careful to use two separate statement-handles, it is perfectly okay to, for example, loop through one query and select each of the records in turn that are mentioned in that query.

I am therefore quite sure that I misunderstood the subtle point you were trying to make – which, I am entirely certain, must indeed have been correct or of course you wouldn’t have said it.   Therefore, could you please clarify your point?   An example of the specific “gotcha” that you are elucidating?   Thanks.

Perhaps Neighbour mixed up MySQL and MS-SQL? MS SQL Server's protocol is limited to one active statement handle per connection. (Recent versions add some dirty tricks to overcome this limit, but they require non-portable, specially crafted code.) DBI has no such limits, neither has DBD::ODBC; and I can't find a hint in the documentation of DBD::mysql that it is limited to a single active statement.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Since “lost connection” is a highly unusual occurrence, yet one which seems to happen to you regularly-enough to mention, I suggest that you need to get to the bottom of this.   Perhaps, for instance, you are trying to send too much BLOB-data at one time and you are overflowing some buffer and in response MySQL is cutting you off.   Like I said, you need to dig deep enough to find out why this is happening to you and to your program, before you start to try to develop an appropriate solution.   Oh, you might manage to find “a Band-Aid® That Seems To Work,” but it is a faux quest.   Forsooth, if you have not unearthed the root cause, your headaches and heartburn will not end.

I agree. No BLOB data, though. This is all cable modem data initially acquired via SNMP. I'm hoping that Neighbour's note that you can't execute a second query while still fetching the results of an earlier query is at the root.