Agent zieht sich trotz Schlüssel die falschen Daten aus einer View.

[Lancelot]

Hallo Leute,

ich habe ein Phänomen und weiß nicht wie ich das gelöst bekomme.

Habe eine Agent der eine TXT Datei einliest und darauf Doc erstellt.
In der Datei stehen Userdaten wie Name, Personalnummer, Abteilung etc.

In einer anderen DB gibt es eine Ansicht mit ein paar Sonderfällen.
Diese Ansicht ist in der 1. Spalte nach Personalnummer sortiert und wenn da ein Doc vorhanden ist,
dann zieht er sich diese Daten, wenn nicht nimmt er die Daten aus der TXT Datei.

Es gibt da einen User der die Personalnummer 91 als Text hinterlegt hat.
Für diesen User gibt es keinen Sonderfall, also auch kein Doc in der Ansicht mit den Sonderfällen.
Aber es gibt in der Ansicht einen User mit der Nummer 9147 und genau die Daten zieht er sich dann.
Das kommt auch nur bei diesem User vor, bei den anderen klappt alles prima.
Datenformate sind beide als String vorhanden.
Leerzeichen wurden mit Trim beseitigt.
Die Datenbank ist Volltextindiziert.
Den Aufruf mache ich per Script wie folgt:

key = Trim$(numstring)   
Set userview = konfigdb.GetView("($konfigview_abtlt)")
Set userdoc = userview.GetDocumentByKey(key)

Ich weiß nicht woran das liegen kann.

Bin für alle Hilfen Dankbar.

Setzen Notes 7.0.3 auf Server und Client ein.

[WildVirus]

Moin Moin,

was passiert denn, wenn Du im Client in die Ansicht gehst, und "91" eingibst ? Dann springt der Cursor zu dem Eintrag, weil er mit 91 beginnt.

Nehme an, dass GetDocumentByKey ähnlich arbeitet.

Mach doch danach eine Prüfung, ob Personalnummer aus Textdatei = Personalnummer aus Ansicht ist. Und fertig ist's

CU,
Axel

[TRO]

Set userdoc = userview.GetDocumentByKey(key)

Set userdoc = userview.GetDocumentByKey( key, True )

hth

thomas

[Felix Ziegler]

Die Funktion GetDocumentByKey hat noch einen zweiten Parameter:

Set notesDocument = notesView.GetDocumentByKey( keyArray [, exactMatch% ] )

exactMatch%
Boolean. Optional. Specify True if you want to find an exact match. The first document that matches the key exactly is returned. If you specify False (the default) or omit this parameter, a partial match succeeds. A partial match returns the first document that matches the initial characters of the key.

Dieser gibt an ob nach einem exakten Treffer gesucht werden soll. Da die Personalnummer in deinem Fall mit 91 beginnt und der zweite Parameter der Funktion GetDocumentByKey standardmäßig auf false gesetzt ist bekommst du als Rückgabewert das Dokument mit der Personalnummer 9147.

Beste Grüße
Felix

[Felix Ziegler]

Hmm... zu langsam... das nächste mal schreib ich weniger Erklärung ;-)

[Lancelot]

Danke Axel, danke Thomas für die schnellen Antworten.

Es funktionieren beide Lösungen und ich muß mich jetzt für eine Entscheiden.

Immer wieder schön über das Froum zu erfahren, wie einfach alles sein kann, doch manchmal sieht man die Lösung nicht, auch wenn Sie einem so vor der Nase liegt.  

Also nochmals Danke an Euch Beiden.

[eknori]

Es gab mal einen Bug, wenn die sortierte Spalte einen numerischen Wert enthielt. Ist die Personalnummer eine "Zahl" in der Spalte oder ist das Text?
Suche mal in dieser Richtung

[TRO]

Es funktionieren beide Lösungen und ich muß mich jetzt für eine Entscheiden.

 

Nimm die dritte 

... beide Lösungen sind doch im Kern identisch!

[Lancelot]

Danke Felix,

und mach Dir nichts drauß, Deine Erklärung hat mir geholfen zu verstehen warum das passiert.
Also bleib bei Deinen Erklärungen.



Danke Eknori,

die Spalte enthält die Werte als reinen Text.
Ich werde aber trotzdem mal weiter suchen, auch wenn ich den Agent jetzt umgeschrieben habe.
Mich interessiert warum das nur bei diesem User passiert ist.
Ich meine es gib noch mehr ähnliche Nummer, da passiert das nicht.

Danke Euch Beiden

[ata]

... ich hatte einen ähnlichen Fall - getDocumentByKey ( sKey , True ) ist auf jeden Fall erforderlich um die Eindeutigkeit zu gewährleisten. Mach in der Spalte noch einen @Text um deine Personalnummer...

Toni

[Lancelot]

Danke Toni,

ein guter Tipp.
Das @Text mache ich auf jedenfall noch in die Spalte rein.

[ata]

... das muß es nicht sein - aber dann ist es wasserdicht - beim Key natürlich auch sicherstellen, daß es sich auch um Text handelt - dann sollte das auf jeden Fall funktionieren.

Toni

[Lancelot]

Den Key habe ich schon im Script extra als Sting konvertiert, auch die Deklaratin ist ein String.

[Bastel123]

Hallo,

ich hatte den Fall das bei einem numerischen Feld "personalnummer" in einer Ansicht in der Selectionsformel stand


Ansicht 1
Select form = "bla" & @Trim(personalnummer) <>""

Ergebnis: 5000 Dokumente in der Ansicht

Ansicht 2
Select form = "bla" & @Trim(@Text(personalnummer)) <>""

Ergebnis: 5600 Dokumente in der Ansicht

Ansicht 2a
Select form = "bla" & personalnummer <>""

Ergebnis: 5600 Dokumente in der Ansicht

auch mit Ytria betrachte sahen die Felder personalnummer gleich aus.

Deshalb bei numerischen Feldern wirklich das @Text nicht vergessen.

Viel Spaß
Sebastian

P.S.
Der Unterschied von 600 Dokumenten scheint noch keinem aufgefallen zu sein.

[ata]

... bist du sicher, daß deine Variablen auch den richtigen Wert enthalten - und hast den optional zweiten Parameter des getDocumentByKey wirklich mit True gesetzt? Irgendwie traue ich dem Braten nicht...

Toni

[koehlerbv]

Hallo Toni,

auf welchen Beitrag bezieht sich jetzt Deine Frage? Die Frage von Gerry war ja mit dem fehlenden Parameter "True" bereits erledigt.

Bernhard

[ata]

... ich wollte nur nochmal alles abfragen - ich weiß daß er es bestätigt hat - aber ich trau dem Braten nicht - GetDocumentByKey funktioniert mit den geschilderten Bedingeungen - wenn es dann nicht tut, steht im Key steht ein anderer Wert, nämlich der, der zu diesem "falschen" Dokument führt...

... oder er befindet sich im Code an einer anderen Stelle - eben mit dem besagten Schlüssel zum falschen Dokument...

Toni 

[Lancelot]

Hallo Bernhard, hallo Toni,

falls sich Eure Diskusion auf mich bezieht kann ich euch beruhigen. 

Meine Variabele ist "DIM String". Im Code selber konvertiere ich nur zur Sicherheit
bei der Übergabe nochmal in Text.
Das Feld in der anderen DB ist ebenfalls Typ "Text" und in der Spalte habe ich ein @Text davor gemacht.
Somit kann auf keinen Fall etwas anderes drinstehen.
Mit dem True im Get DocumentbyKey läuft es nun sowas von prima.

Aber danke für Eure Hilfe.
Es muß auch mal gesagt sein, dass wir hier sehr froh sein können, solche Profis wie Euch Beide, Eknori, Glombi und all die anderen zu haben.
Macht weiter so, auch wenn manche Eurer Wissen nicht so zu schätzen wissen.   

[Glombi]

ich kann mich an einen ähnlichen Fall bei mir erinnern. Trotz true Parameter bei GetDocumentByKey hat er ein anderes Dokument gefunden. In diesem Dokument kam der Key als Anfangszeichen des String vor. Die Lösung war folgende:

In der View habe ich
@Text(Personalnummer) + "#"
programmiert.

Der Key ist dann entsprechend mit dem "#" zu erweitern.

D.h. aus "91" wird dann "91#" und aus "91123" wird "91123#". Damit hat es dann funktioniert.

Andreas

[Lancelot]

Hallo Andreas,

meinst Du das die Sicherheit, die ich jetzt im Moment
nachträglich programmiert habe nicht ausreichen wird?

Hab ja schon gesagt das ich Euer Wissen sehr schätze und wenn Du der Meinung bist, setzen
ich Deinen Vorschlag auch um.

Hauptsache ich bekomme solche Fehler dann nicht mehr.
Es ist immer blöd feststellen zu müssen das der Fehler vor der eigenen Tastatur saß.