Stell mal den Typ der Datenbank auf normale Datenbank (erster Reiter der Datenbank-Eigenschaften, wenn ich mich nicht irre). Wahrscheinlich steht der auf Mail-File

Also, auf die Schulbank musst Du nicht. Das steht tatsächlich meines Wissens nirgends wirklich geschrieben.

Der Datenbanktyp ist auf dem ersten reiter (Basics) der Datenbank-Properties und da gabs in R4.6 grad mal etwa 4 oder 5 Einträge, früher nur grad 2 bis 3. In R5 ist da doch schon eine ganze Liste drin.

Ich vermute, dass der Scheduler diesen Eintrag ebenfalls zu Rate zieht, selber probiert hab ichs auch nicht. Wenn das nix hilft, dann müsste man wohl tatsächlich das Kalenderprofil entfernen.

Interessant zu wissen wäre, was Notes beim Anlegen einer Archiv-Datenbank so alles macht, denn da könnte so ein Problem ja auch mal auftreten.

Wenn das nix hilft, dann müsste man wohl tatsächlich das Kalenderprofil entfernen.

nachdem es am datenbanktyp nicht liegt, weil ja Standard, wie entfernt man so ein kalenderprofil?

ich meine, dieses problem ist ja nicht prio nummer voll high oder so, aber es stoert halt schon, wenn ich in meinem report jeden tag so einen unsinn drin stehen hab, sind ja nicht grad wenig eintraege. muss ja nicht sein.

danke und gruss,
daniela

Kleines Script oder so .... bin aber im Moment auswärts, sonst würd ich jetzt grad mal nachschauen, aber wer anderes springt hier sicher in die Lücke

Dann wäre mal ein Blick mit NotesPeek in eine Resourcen-DB fällig, was da so alles drin steckt. Offenbar wird ja der DB-Typ nicht verwendet. Die Idee mit $Busy-Feldern ist wahrscheinlich gar nicht übel.

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.

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

Hm, $BusyName muss aus dem Dokument ganz 'raus - das Item an sich ist das Leckerli für den Scheduler.
Du schreibst, dass nach @DeleteField das Dokument ganz verschwunden sei. Kannst Du das nochmal erläutern ? @DeleteField haut ja nur das Item in die Tonne, nicht aber das Dokument. Nach einem kurzen Blick in Ansichten habe ich auch dort keinen Bezug auf $BusyName gefunden.

Bernhard

genau das war's !!! ich hab das aus der ansicht "ByDate" rausgenommen, und jetzt sind alle dokumente wieder da !!!  

ich lasse jetzt den agent, der das feld löscht, über alles drüberlaufen, und ab morgen müsste dann ruhe im karton sein, mit diesen blöden fehlermeldungen.

vielen lieben dank nochmal für eure hilfe !!!

gruss,
daniela

Hmm, da wird man sich überlegen müssen, das Calendar Profil gleich ganz rauszulöschen (oder umzubenennen).  Scheint, dass der Task auf dieses Profil "empfindlich" ist.