I'm going to guess the cause is that you have statement handles which you never called finish on before you tried to call disconnect on the main DBI handle. After you're done retrieving results from a handle (as returned from prepare in your sample) you should call finish to let DBI and your database know you're done so it can do whatever it needs to do (freeing up resources, closing whatever, yadda yadda yadda).

ok me i never notic that, that i have to call finish even on select statment, i thought finish is called on update or delete or anything when COMMIT() is called

i tried to call finish on after execute, but db can't allow fetch without excute

i dont think you can call finish when your still fetching info

o.O

• prepare your statement to get a handle
• execute to fetch results
• call whatever fetch routines to retrieve all the results
• WHEN YOU ARE DONE FETCHING RESULTS call finish on the handle

*plonk*

Edit: Obviously from the errors in the OP he's not fetching all the results from the queries and he's not scoping his handles such that they're destroyed before the DB handle is cleaned up, so he either needs to explicitly finish when he's not going to fetch anything more or properly scope the handles so they're cleaned up automagically as documented. Given the historical behavior of the source that's unlikely.

The cake is a lie.
The cake is a lie.
The cake is a lie.

perldoc DBI:

   "finish"
      $rc  = $sth->finish;


    Indicate that no more data will be fetched from this statement han
+dle
    before it is either executed again or destroyed. You almost certai
+nly do
    *not* need to call this method.

    Adding calls to "finish" after loop that fetches all rows is a com
+mon
    mistake, don't do it, it can mask genuine problems like uncaught f
+etch
    errors.
[download]