Domino 9 und frühere Versionen > ND6: Administration & Userprobleme

statistic report DB - fehlermeldung - resource archiv

<< < (3/6) > >>

luna:
dann mach ich mir einfach einen agent, der aus dieser datenbank aus allen dokumenten das $busy feld rausloescht?

das muesst ich doch hinkriegen, oder?  :P

gruss,
daniela

koehlerbv:
Jetzt habe ich mich endlich mal aufgemacht und die KBase bemüht ... Siehe unten - ist ja alles sehr schön beschrieben ;-)

Bernhard




Title:   
      SchedMgr: "Error Validating User While Processing Calendar Appointment"
Product:
Platform(s):
   Lotus Domino  >  Lotus Domino Server  >  6.x, 5.x, 4.6x, 4.5x
      Platform Independent
      
Document Number:   1107085   Date:   17.04.2003



      
      
Problem
While viewing the Notes log, you see the following error message listed:

"Error validating user [user name] while processing calendar appointment (NoteID: NT000021AE) in database mail\[xxx].nsf: Can't find user in Name and Address Book"

What does this error mean and how can this be corrected?



Solution
The error has been noted to occur when using the Calendaring & Scheduling functionality of Notes Client and Domino Server.  When you create Calendar entries such as Appointments in your mail file, the entry from the $BusyName field of the Calendar Profile is input into the $BusyName field of each new Appointment.  The $BusyName is pulled from the "Owner" field which is the editable field at the top of the Calendar Preferences/Profile, labeled "Mail File Owner" or "This Mail File Belongs To".    The $BusyName field for the entry is not visible on the document, but can be seen by selecting File, Document Properties and clicking the Fields tab.

You will see no error when creating Calendaring entries, but the Schedule Manager will generate the above error in the log when it does the validation task.  An error will occur with a unique ID number for each calendar entry which holds an incorrect value in the $BusyName field.  The validation task normally runs at 2 AM; however, it can be forced manually by using the command TELL SCHED VALIDATE at the server console.

A simple agent can be used in the database from which the message is being received.  The agent will change the value of the $BusyName field from the old name to the new name.

The agent should be run from the "Meetings" view of the database.
The agent can be set to run "Manually from the Actions menu" on "All documents in view" or "Selected documents in view".
The agent should be a formula agent and set to "Modify documents".
The formula that can be used is:

FIELD $BusyName := "CN = New Name/OU = OrgUnit/O = Org"


Note: It is unlikely that this issue will occur if the proper procedures to change user's Notes names are used.

Supporting Information:

To accurately find what document is causing the problem, the administrator can use the NoteID Database Tool to analyze the Note ID number which is listed in the error message (for example, NoteID: NT000021AE).

To accurately find what document is causing the problem, the administrator can do the following:

1. Select File, Tools, Administration and click the Database Tools button.
2. Select the appropriate server and mail file that is causing the Schedule Manager to generate the error.
3. From the Tool box, select NoteID.
4. Type the alphanumeric characters that follow "NT", excluding the zeros.  For example, if the Note ID is NT000021AE, type 21AE.
5. Select Find.

The document that is causing the problem will then display.

This issue has been reported to Lotus Software Quality Engineering.

Semeaphoros:
Heisst, wenn man so eine DB archivieren will, muss man das Feld aus jedem Dokument rauskratzen --- Ok, gut zu wissen ....

luna:
hallo,

also, ich hab jetzt mit dem tip vom notes treffen nochmal in der hilfe nach delete field gesucht und folgendes gefunden:

FIELD $BusyName := @DeleteField;
SELECT @All

damit hab ich nur erreicht, dass das komplette dokument verschwunden ist.

dann hab ich's mal damit probiert:

@SetDocField($Ref; "$BusyName"; "");
SELECT @All

aber das tut gar nix.

dann noch damit:

FIELD $BusyName:=$BusyName;
@SetField("$BusyName";"")

damit hat's dann geklappt. jetzt ist das feld $BusyName in jedem dokument leer. jetzt muss ich nur noch abwarten, was der monitoring result morgen sagt, ob endlich ruhe ist, nach dem loeschen dieses feldes.

ich schliesse den call heute noch nicht, warte erst ab, was die monitoring DB morgen so sagt.

vielen lieben dank an euch alle !
gruss,
daniela

luna:
hallo,

also, die fehlermeldung, mit der ich den thread eröffnet habe, kommt in der tat nicht mehr.

dafür die:

SchedMgr: Error processing appointment document (NoteID: NT00003C26) in database sanyo\resbup02.nsf: $BusyName item in appointment document is empty

was würdet ihr mir denn empfehlen, was ich das nächste mal machen soll? es ist ja in 3 wochen wieder aktuell, die datenbank von 2003 wegzusichern. und damit meine monitoring datenbank nicht wieder mit der einen oder anderen fehlermeldung überläuft?

ich könnte sie sicherlich lokal kopieren, und wenn einer was braucht, muss ich halt nachschauen. ist aber blöd, wenn ich in urlaub bin.

habt ihr irgendeine idee, wie ich die von 2003 wegsichern kann, ohne dass der server immer was damit machen will?

danke und gruss,
daniela

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete