CDR Tickets

BZDATETIME::2007-04-12 19:49:24
BZCOMMENTOR::Alan Meyer
BZCOMMENT::1

I just logged onto Bach using Remote Terminal Services and saw
the following error:

Array Configuration Utility encountered a problem and needed to
close. This error occurred at 4/12/2007 at 6:22:41 pm.

Error signature:

szAppName : hpacubin.exe szAppVer : 7.15.19.0
szModName : hpacubin.exe
szModVer : 7.15.19.0 offset : 00022544

Data for the error report that would have gone to Microsoft is
in:

C:\DOCUME~1\ALAN.NIH\LOCALS~1\Temp\1\WEReee9.dir00\hpacubin.exe.mdmp
C:\DOCUME~1\ALAN.NIH\LOCALS~1\Temp\1\WEReee9.dir00\appcompat.txt

A second error occurred:

szAppName : hpacubin.exe szAppVer : 7.73.1.0 szModName : unknown
szModVer : 0.0.0.0 offset : 00000000

C:\DOCUME~1\ALAN.NIH\LOCALS~1\Temp\1\WERa41b.dir00\hpacubin.exe.mdmp
C:\DOCUME~1\ALAN.NIH\LOCALS~1\Temp\1\WERa41b.dir00\appcompat.txt

And a third error (same message) occurred at 6:29 pm.

This is scaring me! I'm wondering if catastrophic failure on
Bach could be imminent!

BZDATETIME::2007-04-12 19:51:55
BZCOMMENTOR::Alan Meyer
BZCOMMENT::2

(In reply to comment #1)
> I just logged onto Bach using Remote Terminal Services and saw
> the following error: ...

Oops.

I meant to post that to 3092. I will repost it there.

Reassigning to Alan

I found it!

I've been looking at this issue, running queries on DEV to find out the nature
of the problem and reading code to see how it could happen.

There is a function in the CdrServer called cdrPutDoc() that is used to insert
or update a document in the database.  If the function is called from XMetal
but validation is not requested, it sets the in memory validation status to
'U' and later, when the document is stored, the val_status column will take
that value.  The place where this happens begins on line 1131 of CdrDoc.cpp
where the following three lines are found:

        // Document is unvalidated.
        // Set status accordingly.  Leaves val_date alone.
        doc.setValStatus (L"U");

The code for this was probably written more than 10 years ago but I have a
vague memory that we (Bob, myself, and Mike Rubenstein) discussed the problem
and decided that the validation date was the date that the document was last
validated.  If the document was stored again but no validation occurred, then
the current val_status is 'U' (unvalidated), but it's still true that the
old val_date is accurate.  The date correctly reports when the document was
last validated.

As I recall, we all had misgivings about this but decided it was better than
the alternative.

To see if this accounts for all of the inconsistent status values I wrote a
number of queries.  Here's what I found:

 1. Every document with:
        all_docs.val_date = all_doc_versions.val_date
     and
        all_docs.val_status <> all_doc_versions.val_status
     has
        all_docs.val_status = 'U'

 2. Every document meeting the above criteria has an audit_trail entry
    for an update with a date later than all_docs.val_date for that document.

I think what is happening is probably correct and no changes are needed.  We
just need to be careful when using the val_date in the all_docs table and
understand what it is.  I have updated the documentation in tables.sql to warn
future programmers about the meaning of val_date.

Neither Bob nor I remembered any of this.  Fortunately, I put the comment in
the code that is quoted above.  If that weren't there this would have been
much harder to figure out.

+1 for code doumentation :)

I'm marking this as resolved - won't fix. I don't think that there's anything to fix at this time.

Resolution of this issue has been set to "Won't fix".

Closing issue.