Autor Thema: Item Sequence Number unterschiedlich trotz gleicher Anzahl Updates?  (Gelesen 2194 mal)

Offline thkn777

  • Aktives Mitglied
  • ***
  • Beiträge: 176
Hallo zusammen,
ich steh' grad auf dem Schlauch, seh' den Wald vor lauter Bäumen nicht oder etwas in der Art. Ich habe hier einen zyklisch laufenden Agenten. Dieser erstellt bzw. modifiziert in den Notes-Dokumenten, die er bearbeitet, drei Items:

DATETIME
HISTORY
MODIFYCOUNT

Ich habe mir nun die bearbeiteten Dokumente angesehen. Aktuell steht bei allen MODIFYCOUNT auf 225, d.h. der Agent hat zuerst eine 1 da reingeschrieben, dann hübsch +1 gerechnet in jedem Lauf. Also je Lauf alten Wert aus dem Dokument gelesen, +1 gerechnet, Wert zurückgeschrieben. Soweit, so gut.

Die Sequence Number des Items MODIFYCOUNT unterscheidet sich GEWALTIG von Dokument zu Dokument: 23 ... 246.

Fragen:
- Wie kann die Sequence Number von einem Item, auf das 225 Updates gemacht wurden, HÖHER sein als 225?
- und woher kommen *hust* 23?

Achja: Außer diesem Agenten greift niemand auf diese Items schreibend zu. Die DB gibt's einmal auf einem Server, keine Replikation, kein gar nichts.

Daß sich die Sequence Numbers der Items im selben Dokument unterscheiden, ist noch so ein Ding. Aber da denke ich erst mal alleine drüber nach.

Habt Ihr Ideen für mich? Ich dachte immer: Änderung --> Sequence Number wird erhöht. Blauäugig von mir, ja?  ::) :-[

Offline it898ur

  • Senior Mitglied
  • ****
  • Beiträge: 478
Hallo,

zumindest die höheren Werte kann ich erklären. Bei einer Änderung wird immer die Sequenz-Number des Dokumentes in das zuletzt geänderte Feld geschrieben. Dadurch führen Änderungen in anderen Feldern zu "Sprüngen" in den Nummern.

Gruß

André

Driri

  • Gast
Alle jemals vom bearbeiteten Dokumente haben einen identischen Wert im Item Modifycount ? Heißt das denn dann auch, daß der Agent tatsächlich bei jedem Lauf alle diese Dokumente bearbeitet ?

Ich frage mich bei der Beschreibung nur, ob da nicht ein Fehler im Agenten ist, so daß immer der identische Wert gesetzt wird.

Offline thkn777

  • Aktives Mitglied
  • ***
  • Beiträge: 176
Hallo,

zumindest die höheren Werte kann ich erklären. Bei einer Änderung wird immer die Sequenz-Number des Dokumentes in das zuletzt geänderte Feld geschrieben. Dadurch führen Änderungen in anderen Feldern zu "Sprüngen" in den Nummern.

Gruß

André

Hm, paßt nicht zu meinen Erfahrungen. Bsp. doc.SN=267 (also dezimal 615), item.SN=103, MODIFY_COUNT=264

Oder gucke ich falsch?
« Letzte Änderung: 29.07.15 - 15:56:29 von thkn777 »

Offline thkn777

  • Aktives Mitglied
  • ***
  • Beiträge: 176
Alle jemals vom bearbeiteten Dokumente haben einen identischen Wert im Item Modifycount ? Heißt das denn dann auch, daß der Agent tatsächlich bei jedem Lauf alle diese Dokumente bearbeitet ?

Tut er... es sei denn, ich würge ihn bewußt zwischendurch ab  ;)

Zitat
Ich frage mich bei der Beschreibung nur, ob da nicht ein Fehler im Agenten ist, so daß immer der identische Wert gesetzt wird.

Gute Vermutung! Aber ich bin ja mißtrauisch, schreibe mehr als ein Item, guck mal:

Code
		If doc.HasItem("CLOI_HISTORY") Then
			doc.CLOI_HISTORY = doc.CLOI_HISTORY(0) & "; " & Str$(Now())
		Else
			doc.CLOI_HISTORY = Str$(Now())
		End If
		If doc.HasItem("CLOI_MODIFYCOUNT") Then
			doc.CLOI_MODIFYCOUNT = doc.CLOI_MODIFYCOUNT(0) + 1
		Else
			doc.CLOI_MODIFYCOUNT = 1
		End If

Wenn ich in CLOI_HISTORY reinschaue, sieht der Wert so aus: "28.07.2015 13:02:31; 28.07.2015 13:08:56; .... 29.07.2015 15:16:37; 29.07.2015 15:21:50; 29.07.2015 15:27:20". Je Eintrag 21 Zeichen inkl. Trennzeichen "; " (siehe Code Schnipsel). Nur der letzte Eintrag hat keinen Trenner.

CLOI_HISTORY ist 5542 Bytes lang und hat eine Sequence Number = 103. 5542+2=5544 (ein zusätzliches Trennzeichen "simulieren". 5544/21=264. Sprich: 264 aneinandergehängte Zeitstempel.

CLOI_MODIFYCOUNT hat eine Sequence Number = 103 und den Wert 264.

 :-:
« Letzte Änderung: 29.07.15 - 15:46:26 von thkn777 »

Driri

  • Gast
Ok, ok, ich glaub es dir  ;)

Ich wollte nur verhindern, daß es nachher dann doch an einem Bug im Code liegt. Kenne ich zur Genüge, wenn man Fehler im eigenen Code sucht und dann dank "Betriebsblindheit" nichts findet bzw. einen Fehler ausschließt.

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz