Domino 9 und frühere Versionen > ND9: Entwicklung
Geöffnetes Dokument aus Domino Datenbank auslesen
Peter Klett:
Bei Deinem "Unterformular" wird es sich um eine eingebettete Ansicht handeln, in der zu dem Kunden zugehörige Dokumente angezeigt werden. An diese Dokumente kommst Du nicht direkt über das CurrentDocument.
Du musst mit dem Schlüssel (z.B. der Kundennummer) aus dem CurrentDocument dann in die Datenbank gehen und Dir z.B. aus dieser eingebetteten Ansicht (oder über ein NotesDatabase.Search) die zugehörigen Dokumente suchen und kannst die dann auswerten. Um zu sagen, wie Du das genau machen musst, fehlt mir allerdings die Kenntnis über Euer eingesetztes CRM.
Du wirst Dich auf jeden Fall mit den Möglichkeiten von LotusScript bzw. den Datenstrukturen von Notes auseinandersetzen müssen. VBA ist sprachlich nicht sehr weit weg von LotusScript, die Unterschiede liegen in den Klassen von Notes, die Du verwenden musst. Umgekehrt kann man mit LotusScript auch die Klassen von Access nutzen, muss dann aber wissen, wie Access tickt.
Tiger955:
Danke für die Erklärung.
Ja, so eine eingebettete Ansicht habe ich vermutet.
Das Hauptproblem bei Notes ist ja diese extrem langsame Abarbeitung von Durchläufen um dann auf bestimmte Feldinhalte eines Dokuments hinzukommen.
Wenn man 2-3 Minuten braucht, um eine Notes-Datenbank zu durchlaufen, nur um aus Dokumenten bestimmte Feldinhalte zu holen, dann ist das im laufenden Betrieb nicht machbar.
Wenn nun mehrere User die Feldinhalte von Dokumenten über den Schlüssel suchen müssen, nur um diese Values in eine relationale Datenbank übernehmen zu können, dann geht auch der Domino-Server in die Knie und unsere IT ist nicht so schlecht bestückt.
Während der Multi-User Zugriff auf den SQL-Server diesen nicht einmal juckt!
Das ist das Drama, welches wir mit Domino haben. Wir brauchen Werte aus dem CRM in anderen Applikationen bzw. in anderen Systemen und können nicht annähernd in "Echtzeit" diese Daten aus dem CRM bekommen. Ganz klar eine absolut falsche Entscheidung ein CRM auf Domino-Basis zu nehmen, wenn der Rest der Applikationen auf relationalen DBs basiert. Aber diese Fehlentscheidung ist bereits vor Jahren gefallen, wir müssen damit leider klar kommen.
Und da auf unser CRM nur die Macher dieses Produkts hingreifen können und dürfen und die lieber ihre "Solutions" verkaufen als uns Daten in eine relationale DB zu schaufeln ist der Weg von Notes --> nach Access (oder andere Apps) so gut wie unmöglich.
Ich bin mir sicher, es wäre bedeutend schneller und leichter mit einem Script die Daten zu fassen, die am Bildschirm dargestellt sind und sie in eine Tabelle nach Access (Backend ist SQL-Server) zu übertragen als von Access aus (VBA) die ganze Datenbank zu durchlaufen.
Für einen Notes-Affinen wahrscheinlich leicht machbar, für mich aus genannten Gründen nicht.
Peter Klett:
Sorry, das kann ich so nicht stehen lassen. Niemand sagt, dass Ihr die ganze Notes-Datenbank durchlaufen müsst, um die Informationen herauszubekommen.
SQL ist genauso ein schlechtes System, wenn ich dort in die Tabellen gehe, und alle Datensätze durchsuche, um bestimmte Informationen zu finden. Dann dauert SQL auch lange.
Es liegt also nicht am System, sondern an der Art der Bedienung.
Wenn Du aus dem aktuellen Dokument die Kundennummer nimmst (die sei der Schlüssel zu den anderen Dokumenten), dann in die eingebettete Ansicht gehst und über die Kundennummer die zugehörigen Dokumente suchst, dauert das keine 2-3 Minuten.
Und wenn das mehrere User machen, geht davon auch nicht der Server in die Knie.
Also bitte nicht über Notes schimpfen und gleichzeitig ausdrücken, dass man davon keine Ahnung hat.
Tiger955:
Dies Reaktion habe ich von einem Notes-Affinen auch erwartet ;)
Nein, im Ernst.
Ich würde Dich wirklich bitten, mir zu schreiben, WIE ich mit einem Schlüssel aus dem Hauptdokument dann auf die verknüpften Dokumente komme.
Was mich verunsichert ist auch Deine Aussage " die sei der Schlüssel zu anderen Dokumenten". Kann es denn auch ANDERE Schlüssel geben. Ich dachte alle NotesDokumente sind über die DocID verknüpft. Alles andere ist doch nicht unique.
Wie gesagt, wenn Du die Option kennst, wie ich einerseits feststellen kann, WAS der Schlüssel ist (bin mir aber fast sicher, dass in unserem CRM die DocID der Verknüpgungsschlüssel ist) und dann, wie ich in die anderen Dokumente programmatisch weitergeht.
Ich kenne nur die Möglichkeit, die entsprechende Datenbank auf die Form zu prüfen und dann den Schlüssel zu suchen. Und das dauert wirklich zu lange, um das andauernd (bei vielen Usern) zu machen.
Set db = session.GetDatabase("", "Test\Doc.nsf")
Set dc = db.AllDocuments
Set doc = dc.GetFirstDocument
While (doc Is Nothing) = False
strItemString = doc.GetFirstItem("Form").Text
If strItemString = "CustomerContract" Then
strDocID = doc.GetFirstItem("DocID").Text
If strDocID = strSearchDocID Then
......
End If
End If
Set doc = dc.GetNextDocument(doc)
Wend
Und ja, Du hast ja Recht, ich habe von Notes wenig Ahnung - daher suche ich hier ja Hilfe!!!
Und nein, ich habe nicht geschimpft, ich habe nur bemerkt, dass es nicht zu UNSERER IT-Landschaft passt.
Wenn Buchhaltung, Fakturierung, Lohnverrechnung, etc. alles über relationale DBs läuft (fast alle SQL-Server) nimmt man doch keine nicht-relationale Datenbank als äußerst wichtige Ergänzung.
Danke
Michael
Peter Klett:
Ok, dann werden wir mal etwas fachlicher.
Natürlich ist die UniversalID der eindeutige Schlüssel zu einem Dokument in einer Notesdatenbank. Das heißt aber nicht, dass jede Datenbank diesen Schlüssel dazu verwendet, um Dokumente zuzuordnen. Ein ganz kleines Beispiel um das zu verdeutlichen.
In einer Datenbank (z.B. einem CRM) gibt es ein Kundendokument und viele zugehörige Auftragsdokumente. Die Auftragsdokumente werden im Kundendokument in einer eingebetten Ansicht angezeigt (das sollte Dir soweit bekannt vorkommen).
Nun kann die Anforderung bestehen, dass es eine Historisierung über die Inhalte der Kundendokumente gibt. Die Änderung eines Kundendokumentes produziert dann jeweils neue Kundendokumente mit einem zeitlichen Gültigkeitsbereich. Jedes dieser Kundendokumente ist ein eigenständiges Dokument in der Datenbank und hat selbstverständlich eine eigene UniversalID. Würde in den Auftragsdokumenten nur die UniversalID des (zum Zeitpunkt der Erstellung gültigen) Kundendokuments gespeichert werden, könnten im später aktuellen Kundendokument die alten Aufträge nicht zugeordnet werden.
Folglich wäre es günstiger, anstatt der technischen UniversalID die logische Kundennummer als Schlüssel zu verwenden. Eine Eindeutigkeit des Schlüssels ist nicht gefordert, da jedes Kundendokument den gleichen Schlüssel besitzen muss.
Soweit zur Theorie. Nun zur Praxis:
Du musst in der Datenbank die eingebettete Ansicht finden. Datenbank öffnen, STRG + SHIFT festhalten und im Menü Ansicht - Gehe zu gibt Dir eine Liste sämtlicher Ansichten der Datenbank, auch die verborgenen (zu erkennen an den Klammern um den Ansichtsnamen).
In der eingebetteten Ansicht wird es eine Kategorie geben, in der der Schlüssel steht (vermutlich die Kundennummer, aber natürlich auch möglich die UniversalID, glaube ich aber nicht -> Kundendokument löschen, neu erstellen -> neue UniversalID, keine Verbindung mehr zu den Aufträgen -> keine gute Struktur).
Dann musst Du im Kundendokument den Feldnamen des Feldes (konkret Item, aber wir wollen es nicht übertreiben mit der Genauigkeit) herausfinden, in dem der Schlüssel steht.
Ich nehme mal an, dass die Ansicht "auftraege" heißt, und das Feld mit dem Schlüssel "kundennummer". Dann würde folgendes Script (LotusScript, sinngemäß in VBA zu übersetzen) in etwa so aussehen. Das ganze natürlich ohne Fehlerhandling und ohne Gewähr auf Tippfehler.
--- Code: ---Dim workspace As New NotesUIWorkspace
Dim kundenuidoc As NotesUIDocument
Set kundenuidoc = workspace.CURRENTDOCUMENT
Dim kundendoc As NotesDocument
Set kundendoc = kundenuidoc.Document
Dim crmdb As NotesDatabase
Set crmdb = kundendoc.ParentDatabase
Dim auftragview As NotesView
Set auftragview = crmdb.GetView ("auftraege")
Dim auftragcol As NotesDocumentCollection
Set auftragcol = auftragview.GetAllDocumentsByKey (kundendoc.Kundennummer (0), True)
Set auftragdoc = auftragcol.GetFirstDocument
Do While Not auftragdoc Is Nothing
'Hier verarbeitest Du die Auftragsdokumente
Set auftragdoc = auftragdoc.GetNextDocument (auftragdoc)
Loop
--- Ende Code ---
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln