Good move calling the guys at Adager.....

Rather than speculate what the problem/solution is best go right to the
big guns....

Brian.

On Mon, 13 Sep 2004 12:03:13 -0700, Emerson, Tom
<[log in to unmask]> wrote:

>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 *

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