ODBCResultSet mit großen Datenmengen

[ralph71]

Hallo zusammen,

ich hole mir über ein ODBCResultSet aus einer MySQL ca. 60000 Datensätze. Diese 60000 Datgensätze muss ich nun ca. 150000 Notesdokumenten zuordnen.
Die einfachste Möglichkeit wäre:
1. View auf die Notesdokumente
2. Jedes Notesdokument Schritt für Schritt öffnen, prüfen ob im ODBCResultSet ein passender Eintrag gefunden wird
3. Wenn ja, dann Notesdokument ändern, wenn nein, dann zum nächsten Notesdokument

Dh. ich würde mein ODBCResultSet 150000 mal durchlaufen.... :-(

Alternativ könnte ich 150000 mal die MySQL-Datenbank anfragen.... nicht so schön.

Gibts ne andere Methode?

Vielen Dank!

[eknori]

ein passender Eintrag gefunden

Wie definierst du den denn?

Wenn ich einen ResultSet aus einer SQl Db verarbeite, dann baue ich mir aus den Informationen einen eindeutigen Schlüssel, quasi die UNID des Einzelnen Eintrags im ResultSet.

Diesen Schlüssel schreibe ich auf das korrespondierende Dokument in der NotesDb.

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.

[ralph71]

Das Notesdokument hat eine eindeutiges Feld (Kundennummer). In der MySQl liegen n-Anzahl Einträge dazu. Dh. ich habe hier eine 1:n Beziehung.
"Diesen Schlüssel schreibe ich auf das korrespondierende Dokument in der NotesDb." --> habe ich also schon gemacht.

Dein Ansatz funktioniert leider nicht, weil Einträge aus der MySQL verschwinden können und damit auch der Eintrag im Notesdokument gelöscht werden muss. Dh. ich muss alle Notesdokumente prüfen.
Aber wie du schon geschrieben hast: "Dann iteriere ich über den resultSet"  --> ich muss also tatsächlich das resultSet iterieren. Eine Suche / Filter o.ä. gibts wohl nicht.

[eknori]

Für das Löschen mache ich es schematisch so.

Ich hole mir aus der NotesDb alle Dokumente mit dem "Schlüsselfeld", und erstelle mir eine Hashmap ( Schlüssel, docUNID )
Dann mache ich meine SQL Abfrage. Bei jedem Eintrag aus dem resultSet lösche ich den korrespondierenden Eintrag in der Map.
Was am Ende übrig bleibr sind dann Einträge in der NotesDb , die nicht im resultSet vorhanden sind. Und die kann ich dann über die docUNID löschen.

[ralph71]

Danke.

[ralph71]

Ich habe jetzt alles hinprogrammiert und es werden bei der ersten Kundennummer brav im ODBCResultSet alle Einträge durchlaufen.
Wenn er fertig ist, dann folgt im Loop wieder:

Res.Firstrow
Do
.....
Res.Nextrow
Loop Until Res.IsEndOfData

Problem: er springt nicht zurück auf den ersten Eintrag sondern bleibt beim letzten Eintrag der ODBCResultSet stehen.
Res.Currentrow und Res.Cachefirstrownum werden trotz
      Res.Currentrow = 1
      Res.Cachefirstrownum = 1
nicht zurückgesetzt. Oder sollte er das bei Res.Firstrow automatisch machen?
Wie schaffe ich den Sprung zurück?

Nachtrag:
hab ich natürlich gemacht...
   Res.Maxrows = 0
   Res.CacheLimit = DB_NONE
   Res.FetchBatchSize = DB_NONE

[CarstenH]

Die folgende Kombination scheint mir ungünstig: zu kleiner Cache für zu großes Resultset

Du schreibst, du setzt

Res.CacheLimit = DB_NONE

Dazu findet man in der Dokumentation:

DB_NONE means that only a very small window, including the current row, is kept in memory.

Du möchtest mit der obigen Einstellung rückwärts springen - dazu findet sich auch etwas in der Dokumentation:

Unless caching is enabled, it may not be possible to set the row at a location before the current row.

Der Cache muss (vorher) groß genug festgelegt worden sein um das komplette Resultset aufzunehmen, du kannst swiw nur innerhalb des Caches rückwärts springen. Ob alles in den Cache passt könnte man bspw. durch Setzen des Caches auf Res.NumRows + x herausfinden oder auf DB_ALL setzen und die erste/letzte Zeile des tatsächlichen Caches abfragen.

Die Logik sagt mir dass der Cache nicht nachträglich auf bereits durch das vorwärts Fetchen aus dem Cache verloren gegangene Rows verschoben werden kann ohne neu zu fetchen aka das Resultset neu aufzubauen.

Möglicherweise ist das zusätzlich abhängig vom Treiber und den dort gesetzten (oder nicht gesetzten) Einstellungen.

[ralph71]

Letzters habe ich gelesen, aber nicht richtig verstanden (und tue es immer noch nicht.... :-( ).

Ich setze zu Beginn:
   Res.CacheLimit = DB_ALL (im IBM-Forum war DB_NONE die richtige Einstellung....  )
   Res.FetchBatchSize = DB_ALL

Im ODBCResultSet stehen bzw. standen schon immer alle Einträge (zu sehen im Debugger).

Unless caching is enabled, it may not be possible to set the row at a location before the current row.

--> und genau da ist das Problem. Wie ist das zu machen?

Sorry, da kann ich setzen was ich will, alles ohne Auswirkung.....

[eknori]

Ich verstehe das mit dem Zurückspringen auf den ersten Eintrag nicht.

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 ?

[CarstenH]

Die Aussage zum Caching und rückwärts springen bezog sich primär auf die Kombination mit DB_NONE, was einen viel zu kleinen Cache zur Folge haben dürfte - daher auch meine Zitate aus der Doku.

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.
Zum Beispiel hier: http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/7a1c88812ab473ba852575d10066d3af?OpenDocument

Was steht denn in CacheFirstRowNum / CacheLastRowNum kurz bevor du den Rücksprung versuchst?

[ralph71]

@eknori

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 ?

--> doch, leider. Dein Ansatz

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.

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)

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.

Wenn ich CacheLimit = 80000 setze hat er auch nur 39832 Sätze im RS.

[eknori]

--> doch, leider. Dein Ansatz

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]

Du hast meinen Ansatz vollig falsch verstanden.

Eine Suche / Filter o.ä. gibts wohl nicht.

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

[ralph71]

Danke