Right... My earlier (in hindsight rather foolish) 'fix' for NET::MySQL didn't work :) A better solution would be to check whether the size of the packet is less than BUFFER_LENGTH (rather than the arbitrary 512 bytes as before) and if so not call recv again (in _get_record_by_serve). However I don't know if the buffer is always garanteed to be full where more data is yet to come. Another fix which I'm using at the moment is, since the last five bytes of the packet always seem to be "\xfe\0\0\x02\x00" for SELECT queries on empty tables, to change the funtion 'sub _has_next_packet' in MySQL.pm to this:

sub _has_next_packet
{
    my $self = shift;
    return substr($_[0], -5) !~ qr/(\xfe\0\0\x22\x00|\xfe\0\0\x02\x00)
+/;
}
[download]

My worry with this fix is that "\xfe\0\0\x02\x00" might on very rare occations be valid table data at the end of the packet... It would be nice to find a mysql doc with what all the end codes actually mean, so I can be 100% sure this is a safe fix..., but I've tried the above on my database and it works beautifully (for now) :)