Re: SQL error - damaged index maybe??

[Al Mac <macwheel99@xxxxxxxxxxx>]

Based on your info, there is still speculation what problem(s).

SAVE ought to identify damaged objects, if you have any.
I had an e-mail on baby steps how to fix when we had a dnamged BPCS file.
If you have no damaged objects, then the problem(s) obviously elsewhere.
If you do have damaged objects, fixing them might not fix all the problem(s).

There are more possibilities as to what the problem might be.

I know a hell of a lot more about BPCS and 400 today than I knew at time of 
original installation, when decisions were made that in retrospect included 
some unwise choices.

We have libraries with vanilla objects that came with BPCS.
We have other libraries with stuff we added, and which came as fixes ... 
PTFs BMRs Rels whatever.
In some cases we have logicals in one library that point at physicals in 
another.

This has an impact on restore from save.
If you restore library containing logicals before you restore library 
containing physicals, the logicals do not get restored for physicals that 
do not yet exist at the time you trying to do this.  This rule of thumb may 
apply to other kinds of objects.

BPCS files can get scrambled in ways that are not IBM problems but are 
problems from perspective of how BPCS software accesses those files.  Do 
you have duplicate index records in files not supposed to have any?  Do you 
have any Data Quality Assurance tools to tell you if records in different 
files are not in sync with each other?

Often running full gamut of BPCS file reorganization programs, that are 
safe to run when not at end fiscal time, will solve a lot of problems.

A lot of BPCS architecture involves files with records identified by 
sequence #s.
Some programs read some detail records on some item order, by going through 
the sequence #s sequentially, always expecting incremented by one.

In a crash, the incrementation can be damaged ... we recently had something 
else go wrong (screwed up the fiscal calendar) that led to more than one 
General Ledger batch with identical Journal numbers (different contents, 
same control #s).

I not now remember exact circumstances but we have had the opposite 
circumstance ... something supposed to have a string of sequence #s 1 2 3 4 
5 etc. but there is like a record # missing in the string & BPCS stops when 
it gets to the hole ... the software thinks it is done processing that item 
order whatever, but there's really more to do.

These sequence #s get propagated across many files ... customer orders ... 
shipping records ... billing invoicing ... receivables ... then various 
BPCS programs use the sequence #s of one file to access the corresponding 
data in another file.

But in a crash, those sequence #s might not have got updated properly, so 
now you can have records in different files without proper pointers to each 
other.s

Al Mac