title: Can't drop a user that is currently connected
body: <p>I'm trying to reinitialize an Oracle DB and am seeing the following error:</p>
  
  <pre><code>  [sql] Failed to execute:  drop user conns cascade
    [sql] java.sql.SQLException: ORA-01940: cannot drop a user that is currently connected
    [sql] Failed to execute:  create user conns identified by conns default tablespace tbs_conns temporary tablespace temp1
    [sql] java.sql.SQLException: ORA-01920: user name 'CONNS' conflicts with another user or role name
  </code></pre>
  
  <p>The problem is that <strong>NO ONE</strong> is connected: this is an instance on my local computer, no outside connections and I <em>just</em> rebooted and have not run anything else. The only thing I can think of is that Oracle might have some background (cleanup?) task running that is causing this issue, but I have no clue how to find/manage that. Any ideas?</p>
  
  <p><strong>Update</strong>: this script actually drops and reinitializes a bunch of tables, and after trying to re-run it a few times, I got the <em>same</em> error message but on a <em>different</em> table: <code>Failed to execute:  drop user csmy cascade</code>. After a few more tries, it moved onto yet <em>another</em> user: <code>Failed to execute:  drop user deb cascade</code>. Something seems to be locking these tables, one at a time, in alphabetical order!</p>
  
  <p><strong>Update 2</strong>: after re-running the script about 15 times - each time failing at a table slightly further along in the alphabet - it has gotten all the way through and things are working. I'd still love to know exactly what happened - my best guess is some background Oracle process, but I have no clue how to check.</p>
  
  <p><strong>Update 3</strong>: I ran into this same issue again the last time I re-ran the script, this time failing on user "cap". To try something new, I fired up sqlplus and manually ran the <code>drop user cap cascade</code> command and, lo and behold, it worked just fine. I tried the script and it ran to completion. Therefore, since manually dropping a user works w/o issues, I strongly suspect the script itself is to blame.</p>