OK, good news first: the good folks at Adager were able to walk our sysadmin through the recovery process -- there was indeed an "in-flight" transaction in a ...00 file, and later grilling of the usual suspects revealed that someone had indeed tried to do something unusual...

> -----Original Message-----
> Behalf Of Brian Donaldson
> On Fri, 10 Sep 2004 14:16:35 -0700, Emerson, Tom
> <[log in to unmask]> wrote:
> 
> >worst thing that can happen on a friday -- "DBG IS DISABLED; 
> > ONLY DBCLOSE ALLOWED"
> 
> Questions--
> 
> 1) Was this data base restored from a partial backup?
> 
> 2) Was the message -- "DBG IS DISABLED; ONLY DBCLOSE ALLOWED" 
> from inside a program updating the database?
> 
> 3) If so, was it using the DBX procedures?

Answers:

  1) no
  2) yes (effectively)
  3) If by this you mean "DBBEGIN/DBEND", then yes (vb using begintrans/committrans)

Probable actual culprit: a user was deleting a massive amount of data -- something like three thousand rows from a purchase order.  The rough VB code for this process went something like this:

     begintrans ' should map to DBXBEGIN
     for idx=1 to spreadsheet.maxrows
        <issue an ODBC/SQL call of the form "delete from header where id=thisOrder">
        <issue another call of the form "select from detail where id=thisOrder>
        while not dataset.eod
            <issue "delete from detail where id=thisOrder & thisLine">
            movenext
        wend
        <issue "select from comments where id=thisorder">
        while not dataset.eod
            <issue "delete from comments where id=thisorder & thiscomment">
            movenext
        wend
     next
     committrans ' and here is the DBXEND

Note the above is boiled down to what "actually" happens; since the usual case is to only delete a few lines, those inner loops actually have a qualifying step to ensure that "this line" (or comment) is actually supposed to be deleted.  In this particular case, the user was deleting ALL lines of the order, so some optimization was being done.

Given that there were 3000+ lines being deleted, I'm almost certain this hit the XM limit for a single transaction (and probably returned an error to that effect)  However, since this now caused "some sort" of problem, everyone else was getting the DBG error and that is what got reported.

What I'm curious about is if I would encounter the same sort of problem if I were to "optimize" it as follows:

     begintrans
       odbc("delete from header where id=thisorder")
       odbc("delete from detail where id=thisorder")
       odbc("delete from comments where id=thisorder")
     committrans

i.e., three simple and distinct "deletes" rather than 6000+ individual deletes.  I'm thinking, however, the likely answer is "yes, the same thing will happen", as this will still "affect" the same amount of data -- can anyone confirm or deny my hypothesis?

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *