So it turns out I'm a goof (this is not surprising), and after posting here, ruminating, and digging through the FreeTDS code, my brain proposed another solution. If I can't have multiple statement handles for a single database handle, can I have multiple database handles, each with its own statement handle? I should try that, right? The solution couldn't be that obvious, right? RIGHT?

Good grief. I just tried it, and it works. I just created two $dbh guys, each with their own $sth; they each called my good friend fetchrow_hashref, and it all went swimmingly.

I understand this is called Rubber Duck Debugging. Now it's time for some Scotch to celebrate. You goofball.

Many database connections don't like more than a single active statement handle that hasn't been completely fetched ("cursor"). I know that SQLite dislikes this.

My usual approach is to either convert the two parallel SQL statements into a single SQL statement, likely with a JOIN, or to use ->fetchall_arrayref to first read all of the rows of the first statement and then process the second statement. My machines usually have enough memory for the second approach.

So it turns out I'm a goof (this is not surprising)

Bolding emphasis mine, which is what I'm responding to here. That's absolute hogwash. You are one of the most methodical, logical and practical thinkers here on Perlmonks, and I've felt that for what, two plus decades.

You hit, as you said, a de-facto situation of Rubber Duck Debugging. You're not the Maple Leafs... you're a Perl Hacker ;)

I know what it's like to have that "sigh, I'm an idiot" moment. Awesome feeling, isn't it!