Domino 9 und frühere Versionen > ND9: Entwicklung

ODBCResultSet mit großen Datenmengen

<< < (3/4) > >>

ralph71:
@eknori

--- Zitat ---Du nimmst nicht ernsthaft das erste NotesDokument und gehst dann jeden Eintrag im RS durch, bis du die korrespondierende row gefunden hast, dann das nächste NotesDokument usw ?
--- Ende Zitat ---
--> doch, leider. Dein Ansatz
--- Zitat ---Dann iteriere ich über den resultSet, hole mir einen Eintrag und suche das korrespondierende Notes Document entweder über db.search oder in einer View. Kommt ein bisschen darauf an, ob ich das Design einer Db anpassen kann oder nicht.

--- Ende Zitat ---
funktioniert leider nicht, da Einträge aus dem RS verschwinden können und damit im Notesdokument gelöscht werden müssen. Basis muss der Notesview sein. Dein Ansatz funktioniert nur, wenn ich vorher alle Einträge in den Notesdokumenten lösche und neu schreiben lasse. Das kann ich wegen Replikation usw aber nicht.
Ich könnte irgendwie einen join zwischen RS und View programmieren, um dann alle Kundennummern zu erhalten, die nicht im RS stehen, die dann durchgehen und Einträge (wenn vorhanden) löschen. Hm.

@CartenH
... jetzt kommen wir der Sache schon näher.

Bei CacheLimit = DB_ALL
FIRSTROWNUM = -1
LASTROWNUM = -1
CACHELIMIT = 0
CURRENTROW = 50085


Bei CacheLimit = 50085
FIRSTROWNUM = 1
LASTROWNUM = 39832
CACHELIMIT = 50085
CURRENTROW = 39832 --> kann nicht sein. Es sind 50085 Einträge
ABER: hier setzt er den RS wieder zurück auf 1. (hat aber nur 39832 Sätze im RS)


--- Zitat ---Die Einstellung DB_ALL sollte zwar Abhilfe schaffen aber in verschiedenen Foren ist zu lesen, dass dieser allgemeine Parameter nicht immer funktioniert und in den Fällen das Setzen eines festen Wertes (der mindestens der Größe des Resultsets entspricht) Abhilfe geschaffen hat.
--- Ende Zitat ---
Wenn ich CacheLimit = 80000 setze hat er auch nur 39832 Sätze im RS.

eknori (retired):

--- Zitat -----> doch, leider. Dein Ansatz
--- Ende Zitat ---

MEIN Ansatz?? No way.

Ich iteriere über das RS und hole mir dann das korrespondierende Notes Dokument.

ralph71:
bitte ganz lesen:
Dein Ansatz Zitat"....." funktioniert leider nicht,..... :-)

... hab ich schon verstanden

CarstenH:
Dann haben wir doch schon 2 Probleme gefunden.

1. Meine erste Vermutung, dass das RS nicht in den Cache passt, war scheinbar zutreffend. Ob hier der Treiber oder irgendwas anderes limitierend ist sieht man ja leider nicht.

2. Du hast scheinbar ein Folgeproblem, das mir sehr bekannt vorkommt. Sobald das Cache-Ende erreicht wird fetcht er scheinbar nicht weiter - zu sehen an der Diskrepanz zwischen CurrentRow mit und ohne Cache. Das wird auch der Grund sein, warum in einigen Foren DB_NONE empfohlen wird, da hier gezwungenermaßen nach jedem Datensatz ein neuer Fetch stattfindet während sich das Script bei der Cache-Variante nur aus ebendiesem bedient, danach folgende Daten werden nicht mehr geliefert (kontrolliere es mal).

Ich musste zur Lösung von Problem Nr. 2 mein Script umbauen: ich zähle zuerst mit einem reinen Select Count und prüfe anschließend während der eigentlichen Ausführung ob wirklich das Ende erreicht wurde - anderenfalls kommt ein neues Select, beginnend ab dem letzten Eintrag des ersten Sets. Das hilft dir jetzt nur bedingt, letztendlich wirst du deine Strategie komplett überdenken müssen wenn die Daten nicht in einem Rutsch verarbeitet werden können.

eknori (retired):
Du hast meinen Ansatz vollig falsch verstanden.


--- Zitat ---Eine Suche / Filter o.ä. gibts wohl nicht.
--- Ende Zitat ---

https://www.ibm.com/support/knowledgecenter/en/SSVRGU_8.5.3/com.ibm.designer.domino.main.doc/H_LOCATEROW_METHOD.html

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete