I can't tell you for sure the cause of this strange behavior, but there are a couple of things that are worth saying about your problem.

• You are using fetchrow_array only once, without a finish statement. This fact might be the reason for the DB engine being out of synch with its cursor.
  The usual way of calling fetchrow_array is within a loop. This way, when it returns undef, the DBI calls finish for you. If you are sure that there will be only one record, then issue a $sth->finish call.
• (Unrelated to the specific prolem) You are using fetchrow_array in scalar context. In this particular case, it should be no problem, but be aware that it may have unpleasant side effects if you select more than one field. (See DBI specification change)

HTH

Update

Just to explain better my story. The call to finish is always necessary. There are times when the DBI calls finish implicitly, for example, when you use a call to fetchall_* or selectall_* functions. The finish is also implicit when the fetch function is inside a loop. In all the other cases, you should call it. And, just to be paranoid, if you call it even after a loop, you don't do any damage. :)

A driver can be implemented in such a way that a call to finish is not necessary. For example, if the driver uses some sort of "fetch-at-once" mechanism, then the finish is not needed, because the driver itself, internally, has already retrieved ALL the records.

Update (2)

The DBI docs say that the driver should call finish "when all the data has been fetched." The driver has two ways of know that *ALL* the data is fetched: either you call a "fetch-all-at-once" routine or you call a "fetchrow_*" in a loop until it returns undef. When one of these cases happen, the driver calls finish.

If you call a fetchrow_* function only once, the driver does not know if there is more data to fetch or not.

 _  _ _  _  
(_|| | |(_|><
 _|
[download]