Missing documents in GW 5.5.1
danita at caledonia.net
Wed May 26 21:21:04 UTC 1999
I just asked someone at Novell who says she hasn't heard anything about this at all. I'll see if anyone else will admit to knowing about this <g>.
>>> "Danita Zanrè" <danita at caledonia.net> 05/26/99 03:00PM >>>
Actually, here is the only place I've heard of this, so I'm doing some checking!
>>> "George Atkins" <GKA at iotadev.com> 05/26/99 01:44PM >>>
I had the client locate a backup tape of one of the offending library database files and restore it, then do an index rebuild. So far, it appears that lots of documents are now showing up, which is good. Now, I have to track down why they are getting all of this corruption. I'm wondering if it is their backup. They are using ArcServe with the GW snap-in. But I've heard that there might be a problem with this. Has anybody heard anything?
>>> "George Atkins" <GKA at iotadev.com> 5/26/1999 11:26:09 AM >>>
Well, had the client run all of these procedures, but the problems still exist. Ugh! Any other ideas? They get ALL kinds of error messages, many of them the "standard" kinds of stuff you see in the index logs: C07B, F040, even 823, E811s, etc.
I have just found out that the indexing server has a netware license problem - the one about activating the lic. key. The client is having the vendor fix that problem. Could that be an issue?
I have also heard that Novell is talking closely with the ArcServe people about corruption of GW indexes. Our client uses ArcServe with the GW snap-in. But perhaps the snap-in is not as bullet-proof? Have you heard anything?
>>> "Danita Zanrè" <danita at caledonia.net> 5/25/1999 2:35:23 PM >>>
I think you have some database corruption. The fact that they all end in 9 is easily explainable. You have ten DMDD and ten DMDL files in your library directory. Each one contains either the document profiles or the access logs for a "partition" and a partition is the group of documents all ending in the number of that partition. So the profiles for all documents ending in 0 are in the DMDD000x.db file (the "x" is the number of the library). It sounds like the "9" of these databases is bad. So, do this. First run a GWCHECK on the library - Analyze and Fix Structure. Then Analyze and Fix Contents. After that rebuild the indexes and the library should be okay.
>>> "George Atkins" <GKA at iotadev.com> 05/25/99 12:59PM >>>
I have a client running 5.5.1 with doc mgt in a c/s configuration. They are complaining that documents are getting lost, though the profiles are still available. They receive an E811 error when trying to open the doc or view the property sheet. Some comments from the administrator:
1.The E811 errors are not only for newly created documents, but also for some older documents (created in December, public security, not archived).
2. The error E811 indicates that the document version does not exist or the user does not have security, however, the document number appears as, i.e. 52569.0 (I also tried to pull it up by specific version (52569.1 and 52569.2) and get the same message though.
3. In my list of problem documents that won't open due to E811 errors, all of them end in 9. (Document Nos. 52649, 51879, 51879, 52569, etc.). The old document from December that would not open is 46889.
This last comment is especially strange (to me, anyway). I've never heard of such a thing.
We've tried virtually every maintenance trick that i can think of - even the normal ones, such as rebuilding all doc databases, po, rebiulding the indexes, verifying indexes, etc.
Any ideas at all? Thanks for any ideas
More information about the ngw