AtNotes Übersicht Willkommen Gast. Bitte einloggen oder registrieren.
16.11.18 - 00:19:37
Übersicht Hilfe Regeln Glossar Suche Einloggen Registrieren
News: Die Boards zu Version 10 sind verfügbar!
Schnellsuche:
+  Das Notes Forum
|-+  Lotus Notes / Domino 9
| |-+  ND9: Entwicklung (Moderatoren: Axel, eknori, Thomas Schulte, koehlerbv, m3)
| | |-+  "stampAll" für flag IsReaders
« vorheriges nächstes »
Seiten: [1] Nach unten Drucken
Autor Thema: "stampAll" für flag IsReaders  (Gelesen 279 mal)
tabama
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 232


hier werden Sie geholfen


« am: 08.11.18 - 15:12:27 »

Hallo,
mit der DC-Methode "StampAll" ist es ja möglich, den Wert eines Items für alle in der DC enthaltenen Docs zu setzten.
Ich suche eine Möglichkeit, dies für den Flag "IsReaders" eines Readerfeldes zu tun.

Hintergrund: Ich importiere monatlich ca. 150.000 Datensätze in eine Datenbank. In der Importdate sind bereits die Inhalte der Readerfelder belegt. Damit das aber auch in Notes funktioniert, muss ich noch den Flag setzten.

Wenn ich mich mit "while not doc is nothing" durch die DC wühle, dauert das sehr lange. Deshalb suche ich eine andere Lösung.

Es muss auch nicht aus einer DC heraus sein. Ich möchte alle Dokumente der DB stempeln.

Gibt es so was?
Gespeichert
ronka
Aktives Mitglied
***
Offline Offline

Beiträge: 196


Was macht der hier denn, muß der überall sein ?


WWW
« Antworten #1 am: 08.11.18 - 22:24:09 »

Nein, das geht nicht mittels Stamp All, damit kann nur einen WERT gesetzt werden, nicht einen Typ.

Dafür musstest du jedes feld als NotesItem holen, und dort der wert des Items mittels IsReader=True setzen.

Sprich einen ForAll oder einen While-Do schleife erstellen und durch ALLE dokumente gehen.
Gespeichert

das neueste von Domino 10 auf den AdminCamp in September -> www.AdminCamp.de
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6084


Geht nicht, gibt's (fast) nicht... *g*


« Antworten #2 am: 09.11.18 - 08:14:41 »

Sind es denn jedesmal andere / neue  150.000 Dokumente, oder ist das nur einfach so Sch... programmiert, dass monatlich die selben 150.000 Datensätze gelöscht / neu angelegt werden, weil man nicht weiss, wie es richtig geht?
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
tabama
Aktives Mitglied
***
Offline Offline

Geschlecht: Männlich
Beiträge: 232


hier werden Sie geholfen


« Antworten #3 am: 09.11.18 - 11:45:20 »

Hallo Thorsten,

es sind zum Großteil immer die Gleichen. Es kommen ein paar hinzu und ein paar fallen weg.
Bisher war der "Sch..." auch das Einfachste. Ich brauchte mir keine Gedanken über das "Update-Thema" zu machen. -> Löschen, Import, Fertig!

Nun ist aber jemand auf die Idee gekommen. dass nicht mehr jeder alles sehen darf. Deshalb nun die Reader-Felder. Wenn es mit dem "stampAll" odgl. nicht geht (was ich schon vermutete), muss ich mir nun mal Gedanken machen, was auf Dauer mehr Sinn macht. (Löschen und neu, oder Update).

Vielen Dank für die Antworten.
Gespeichert
Peter Klett
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 2554



« Antworten #4 am: 09.11.18 - 12:35:18 »

Löschen und Neu ist die allerschlechteste Lösung in Notes. Replikation und Deletion-Stubs seien nur zwei Stichworte
Gespeichert
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6084


Geht nicht, gibt's (fast) nicht... *g*


« Antworten #5 am: 09.11.18 - 14:11:44 »

Boah... 150000 Datensätze monatlich löschen.... würde mich nicht wundern, wenn Euch diese Applikation irgendwann um die Ohren fliegt...
Es ist doch so einfach, bei einem import zu prüfen, ob ein Dokument schon da ist oder nicht:

1. Ansicht, sortiert nach "eindeutigem Schlüssel". Wenn der nur eindeutig ist, wenn man alle Felder miteinander verknüpft, dann ist das halt so. 2. Spalte: @Text( @DocumentUniqueID)
2. Vor Beginn des Imports diese Ansicht iterieren und eine Liste mit den existierenden Schlüsseln erstellen. Eine Liste mit 150.000 Dokumenten könnte wird speichertechnisch problematisch sein, deshalb würde ich hier mit UNID arbeiten:

Code:
Dim lstrUnid List as String
'- Ansicht durchlaufen und für jeden ViewEntry:
lstrUnid( ViewEntry.ColumnValues(0) ) = ViewEntry.ColumnValues(1)

Dieses Vorgehen hat den Vorteil, dass man später nicht 150.000 Lookups machen muss, die die Laufzeit sprengen

3. Für jeden importierten Datensatz Schlüssel bilden und schauen: ist in Liste? Wenn ja: Dokument per Unid holen, Updaten (oder sogar prüfen, ob man updaten muss, hier arbeite ich gerne mit Hashwerten wegen der Performance), und Eintrag aus Liste entfernen. Wenn nein: Dokument neu erstellen

4. Am Ende sind alle Einträge, die in der Liste noch drin sind, nicht mehr im Quellsystem: UNIDs durchlaufen und Dokumente löschen...

Ohne Hashing- Vergleiche sind das max. 100 Zeilen Code. Wenn man zur Performance- Optimierung auch noch Hashed und die Hashes vergleicht, dann sind es vielleicht 200 Zeilen Code...
« Letzte Änderung: 09.11.18 - 16:25:42 von Tode » Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
Peter Klett
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 2554



« Antworten #6 am: 09.11.18 - 14:35:23 »

...
Eine Liste mit 150.000 Dokumenten könnte Speichertechnisch problematisch sein, deshalb würde ich hier mit UNID arbeiten:
...
Völlig einig, nur das Wort "KÖNNTE" ist hier m.E. falsch, da müssten die Dokumente schon sehr klein sein, damit das problemlos geht. Wink
Gespeichert
Tode
Moderatoren
Gold Platin u.s.w. member:)
*****
Offline Offline

Geschlecht: Männlich
Beiträge: 6084


Geht nicht, gibt's (fast) nicht... *g*


« Antworten #7 am: 09.11.18 - 16:26:18 »

Hast vollkommen recht, ich habe das korrigiert: könnte -> wird
Gespeichert

Gruss
Torsten (Tode)

P.S.: Da mein Nickname immer mal wieder für Verwirrung sorgt: Tode hat NICHTS mit Tod zu tun. So klingt es einfach, wenn ein 2- Jähriger versucht "Torsten" zu sagen...

Mit jedem Tag meines Lebens erhöht sich zwangsweise die Zahl derer...
... denen ich am AdminCamp ein Bier schulde... Wenn ich hier jemanden angehe: Das ist nie persönlich, sondern immer gegen die "Sparwut" der Firmen gedacht, die ungeschultes Personal in die Administration unternehmenskritischer Systeme werfen... Sprecht mich einfach am AdminCamp an, ich zahle gerne zur "Wiedergutmachung" das ein oder andere Bierchen an der Bar
Seiten: [1] Nach oben Drucken 
« vorheriges nächstes »
Gehe zu:  


Einloggen mit Benutzername, Passwort und Sitzungslänge

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2006, Simple Machines Prüfe XHTML 1.0 Prüfe CSS
Impressum Atnotes.de - Powered by Syslords Solutions - Datenschutz | Partner: