Sletten Kenneth W wrote:
> Jeff expresses understandable concern after I and others posted:

> > If there are any details of this problem I'd like to KNOW about them
> > NOW, not after the problem is resolved.  I've already had some
> > suspicious problems (four IMAGE databases with corrupt datasets
> > with actual capacities exceeding the root file entry counts - this
> > after a simple :STORE from the old system and a :RESTORE onto the
> > new 969).  Is this related?  Are my databases being corrupted into
> > oblivion?

Let me clarify before I'm taken out of context, the "DATA" was NOT
corrupt, it was quite intact and passed integrity checking.  It was
merely the entry counts that were "corrupt".

If the new system were not in production I would try to recreate this
problem, but I would have to twist the scenario as to restore into
another account and/or group and I don't have the original store media
that I used (I was using TS7x24 store to disc to migrate the system over
the weekend from home without having to bother with tape mounts, and I
only had enough scratch disc to move so much at a time...)

Yes, I also suspected TS7x24, but nobody was on the "old" system, the
network was shutdown (I was on a dialup serial), and I wasn't using one
of the online options.  Nobody was on the "new" system either as it was
using an unpublished/non-DNS temporary IP number at the time.

We run DBLOADNG weekly on all of our databases.  All were clean on the
old system prior to the move.  The first one on the new system showed
the corruption and the Bradmark utility verified that it was indeed
corrupt (well, again, not corrupt, but the entry counts disagreed with
the actual records read).

The only other "variable" in the mix is that the new system is using a
mirrored user volume set while the old one did not, but I doubt that is
relevant (but just in case it rings a bell, thought I would mention it).

Jeff Kell <[log in to unmask]>