| Hi Tim. I can provide a brief description of what needs to be
done. It's not always possible to fix these corruptions. It
depends upon how serious the damage is.
Start with the users .A1CAL file. The indexed key is the first 16
characters (called .CAL_KEY), of which 13-16 are used to prevent
duplicates. The field called .MEETING_POINTER is 46 characters
long is composed of two fields (schedulers name, 30 characters and
start date and time pointer in meeting.dat, 16 characters). The
date and times need to match for these two fields. The two sets
of 4 character uniquifiers may be different. The last field of
interest is .TYPE and should have a value of M for an event with
attendees. The schedulers name must not be blank for an event
with .TYPE = M.
The data in MEETING.DAT must then be checked. You may have to
create new records to fix the problems. From DCL, do a
READ/KEY="value of .MEETING_POINTER" to get the record.
There is then one record in ATTENDEE.DAT for each of the attendees
to the event. The indexed key is the first 76 characters composed
of .MEETING_POINTER and .ATTENDEE_NAME. Sometimes these records
also do not exist.
The key to correcting these problems is finding the proper value
for .MEETING_POINTER, making appropiate corrections to
MEETING.DAT, ATTENDEE.DAT and the attendee and scheduler .A1CAL
files.
Dave Zaniewski
PS, not all the corruptions are prevented with the patch you
mentioned.
|
| Dave
How do you clear up the corruption of too many attendees for a meeting?
It would seem that the meeting pointers have to match or the attendee
would not show up on the meeting but how am I to know, by looking at
the ATTENDEE.DAT file, that an attendee record is valid or invalid.
What corruptions still exist and how can they be avoided?
Thanks
Tim G
|
| Dave already gave a pretty good overview in .1. There's a couple of
approaches you can take, depending on whether you want to simply remove "error"
records, or totally clean up the entire data base. (I differentiate between the
two, in that the first just gets rid of any records that could cause direct
errors, but could end up leaving "dead" entries in ATTENDEE.DAT -- entries that
will *never* go away; the second is more like a "verify and repair".)
To accomplish the latter, you'd have to do as Dave said -- go through
each user calendar file, check for all meetings, check the meeting pointer field,
look that up in the MEETING.DAT record, check for all entries in ATTENDEE.DAT
with that meeting pointer, etc. It's not that difficult -- just time-consuming.
(Although, if you *do* write something like that, let us know; it'd be a great
utility to have around!)
In your case, you might be better off just walking through the ATTENDEE
data file and verifying that everything there *should* be there. Each record in
ATTENDEE.DAT should a) have a corresponding record in MEETING.DAT (this does not
indicate a one-to-one correspondence; more than one ATTENDEE record can -- and
usually does -- point to the same meeting record), and b) each record in a user's
calendar that is a Meeting should have a related entry in the ATTENDEE file,
keyed on the meeting pointer plus the attendee's name.
If either is out of synch, you'll have to decide what to do about it
(the simplest being to blow away the one that *does* exist, at the cost of losing
the information).
If I get a few minutes, I'll try to put together some code to help
explain what I've described.
F
|