getdocumentbykey(key,true)

[AC]

tut nicht was es soll, (bzw hat es einmal gestern nicht getan), obwohl er es tun müsste .

Bin sehr ratlos weil ich alles durchgecheckt habe.

Hi Leute,

Fehler trat auf bei einem Aussendienstmitarbeiter ( wobei ich leider bei dem auch nicht ans Notebook und damit den Client rankomme).

Gibt keinen Grund, weshalb es diesesmal bei zwei Dokumenten nicht funktioniert hat, sonst ging es auch immer. Bei ihm und auch bei andern Kollegen.  Und an den Daten kann es nicht liegen.

Gecheckt:
Der view in dem ich suche hat den richtigen Namen.
Der Zugriff für den User auf das gesuchte Dokument ist ok.
Das Feld das ich zum Suchen benutzen ist ok und hat exakt den richtigen Wert.
Ich habs hier mal bei mir durch "gedebugged" und keinen Fehler gefunden (auf der Replik) bzw Server .
Der Schlüsselwert mit dem ich suche ist exakt ok.
Das Dokument das ich suche ist vorhanden.


Wenn es an der Programmierung läge dürfte es bei mir auch nicht klappen (exakt die gleichen Daten) und was den Zugriff amgeht, so kann es da auch nicht daran liegen.

Das einzige was ich mir vorstellen könnte, daß aus irgendeinem blöden Grund, diesesmal zufällig der view nicht geöffnet werden konnte. Warum auch immer......

(Blöder einmaliger Zufall?)

Hat jemand eine Erfahrung gemacht? Tips ?

Ich arbeite oft mit getdocumentbykey und hatte nie ein Problem.


Merci
Holcomb




 

[klaussal]

standardfrage: spalte sortiert ? gehe ich mal von aus.

hab sonst keine erklärung. also doch ran ans notbook  

[AC]

standardfrage: spalte sortiert ? gehe ich mal von aus.

hab sonst keine erklärung. also doch ran ans notbook  

Jou, Ansicht ist kategorisiert und aufsteigend.

Vielleicht hat es den Viewindex zerlegt (keine Ahnung warum). Ich werde den Aussendienstkollegen mal den Tip gehen, in den view selbst mal reinzugehen und ein shift F9 zu machen.

Wenn das auch nichts bringt, bin ich auch ratlos.


Gruß Holcomb

[Glombi]

Außendienstler und Notebooks sind eine gefährliche Kombination  

Hast Du mal geprüft, ob er vielleicht das Dokument gelöscht hat oder dort den Schlüsselbegriff geändert hat?
Arbeitet die Anwendung mit Leserfeldern und konsistenter ACL? Hat er vielleicht eine 2. ID mit der er "versehentlich" arbeitet.
Vielleicht ist auch der Viewindex in der lokalen Replik beschädigt. Hier hilft ein <Strg>-<Shift>-<F9>, wenn der User die Rechte hat.
Steht was im lokalen Log.nsf des User, was auf Probleme mit der DB deutet?

Andreas

[AC]

Hi Glombi,

danke für die zahlreichen Tips.

Am Dokument selbst ist nichts passiert, das ist sicher (wiurde auch schon wieder repliziert so daß ich hier dies sehen würde, wobei an das Dokument sowieso nur der LEI hingeht)

Zugriff passt auch kein Problem.
Gibt auch keine ZweitID.  (an was man alles denken kann).

Viewindex auf der lokalen Replik ist das Stichwort.
Das vermute ich auch mal.

Aber nun zum Procedere.
ctrl shift F9 benutze ich immer um alle Views der DB zu aktualisieren.
Baut er den Viewindex dann neu auf ?
Oder müsste ich den Viewindex nicht komplett am Client löschen lassen und dann neu aufbauen, wenn der Index beschädigt ist ?

Ich hätte den Benutzer nun mal zu Fuß in den View gehen lassen und ihn dann ein shift F9 vollziehen lassen.

Hilft das oder muß man zum Indexreparieren auf den Client noch was anderes beachten ?

Vielen Dank erstmal für die schnellen Antworten.

Holcomb.  

 

[klaussal]

shift + F9 sollte reichen.

[Glombi]

Wenn es eine View ist, in die der User "normal" hereinkommt - also eine sichtbare - kann er den Index dieser View mit <Shift>-<F9> aktualisieren.

Bei lokalen Anwendungen hatte ich auch schon mal Streß, wenn die Desktop5.dsk zu groß geworden ist. Der User sollte mal sicherheitshalber seinen Arbeitsbereich komprimieren.
Ausserdem sollte er danach mal Notes schließen, die cache.dsk löschen und Notes wieder starten.

Machst Du den GetDocumentByKey in die gleiche Datenbank oder gibt es eine eine andere?

Andreas

[AC]

Hallo Klaussal und Glombi.

Der view ist in eienr anderen DB. Aber wie gesagt kein Prob von der Programmierung her.

Der Tip mit der Dekstop.dsk und der Cache.dsk ist auch gut.

Ich werde beides mit ihm am Abend mal via Telefon dann durchgehen.

Wenigstens ist es ein user, der einigermaßen fit ist und denn ich ohne Angstzustände auch den Dateiexpolrer öffnen lassen kann und die cache.dsk löschen lassen kann. :-)

Wie hat sich das mit der zu großen desktop.dsk bei Dir geäussert ?

Gruß Holcomb.
PS Zur Info Kann erst heute abend oder morgen wieder antworten

[Glombi]

Der view ist in eienr anderen DB. Aber wie gesagt kein Prob von der Programmierung her.

Hatte ich als eine Ursache vermutet, falls der Index doch ok ist: Der User hat vielleicht 2 Repliken auf seinem Notebook. Eine vollständige und eine weitere, die mal versehentlich angelegt wurde (Sicherungskopie ?).
Wie holst Du die Ziel-DB: Per Replik-ID (wahrscheinlich bei verteilten lokalen Notes-Anwendungen sofern nicht eine Config DB a la LSA da ist) oder per Pfad?

Wie sich ein übergelaufene desktop.dsk äußert: Es funktionieren @DbLookups nicht mehr korrekt - sowas in der Art.

Andreas

[AC]

N´Abend Glombi.

2 Repliken scheiden aus. (Aussendienst zieht sich keien Repliken außer ich coach die am Telefon, wie sie es machen müssen)  

Ich hole die DB mit Pfad.
Allerdings erzeuge ich in der gleichen DB mit der gleichen Routine auch ein Dokument und das hat er auch korrekt getan.
Insofern hat er auf jeden Fall die DB.

Mein getdocumentbykey ersetzt ein computewithform damit eben bestimmte Werte in der Maske gesetzt werden.

Zu große desktop.dsk.
Gibts da Erfahrungswerte ? Kann man da eine ungefähre Größe sagen, bei der man da eine Komprimierung machen sollte ?



Gruß, Holcomb
PS Bei Gelegenheit, wenn ich den Aussendienstler abends mal in Ruhe am Tel bei offenem Notes erwischze werde ich auch mal die lokale log.nsf durchstöbern.

[Glombi]

N´Abend Glombi.
Mein getdocumentbykey ersetzt ein computewithform damit eben bestimmte Werte in der Maske gesetzt werden.

Das versteh ich nicht   Was meinst Du mit "ersetzt" ?
Kannst Du mal den Code posten, evtl. kann man dann was sehen.

Was ist denn der Key für GetDocumentByKey? Evtl. ein Datum, welches durch ein "falsches" Format des Notebook nicht gefunden wird? Oder eine Zahl?

Andreas

[AC]

Ich erstelle mit einem Skript aus DB1 in einer "anderen Datenabank" DB2 ein Dokument.  In der Maske für das "neue" Dokument sind ein paar @DBLookups in manchen Feldern (auch aus DB2).
Statt diese Felder mit computewithform berechnen zu lassen, hole ich mir die zu setzenden Werte eben über Script mit getdocumentbykey.

Doch hier ist wirklich nicht das Prob. Hat tausendmal funktioniert und wird auch noch viel öfter funktionieren. Es stimmen auch die Daten für meinen "Fehlerausreisser".  Habs ja auch hier lokal bei mir gedubugged mit den Originaldaten die den Fehler verursachten. (im Script fang ich es dann ab mit einer Fehlermeldung falls doc nothing ist wenn der getdoumentbykey fehlschlägt). Diese Fehlermeldung kam beim Aussendienstler eben obwohl sie nicht hätte kommen dürfen.

Daher meine Vermutung: Viewindex kaputt.
BTW Kann man einen defekten Viewindex via Script abprüfen ?
(In der view klasse finde ich da nix)

Der Key ist die Kundennummer.
Wobei da eine Spezialität ist (die aber bisher NOCH NIE ein Problem verursacht hat). DIe Kundennummer kommt bei uns über LEI und ist rechtsbündig 5 stellig und hat 3 führende blanks (kommt über LEI aus AS/400) .
Aber auch das war noch nie ein Problöem und ist natürlich auf beiden Seiten so.  In der Ansicht erste Spalte in der ich suche als auch im key.

Das zur Erklärung.

Die Blanks: Normalerweise mache ich bei sowas ein TRIM, aber da die Anwendung in DB2 schon länger bestand und produktiv war, wollte ich da nicht reinfuhrwerken und fand mich mit den blanks ab. Und an denen liegt es auch nicht, sonst würde es öfter Ärger geben.  


Daher kann es an sich nur der Viewindex sein (oder vielleicht doch zu große desktop.dsk) und ich hab keine Ahnung wie ich sowas in Zukunft verhinden kann.

Gruß, Holcomb

[AC]

Ergänzung: mit DB1 und DB2 meine ich die notesdatenbanken eins und zwei ,  nicht das das zur Verwirrung und Verwechslung mit
einer DB/2 Datenbank führt. (hätte auch schreiben können nsf1 und nsf2)

[koehlerbv]

Funktioniert das bei Deinem Aussendienstler eigentlich jetzt prinzipiell nicht mehr oder "nur" bei bestimmten Abfragen ?
Für den erforderlichen Neuaufbau der View-Indizes spricht natürlich viel (Aufbau aller - wenn einer putt ist, misstraue auch den anderen in dieser DB).

Bernhard

[AC]

Funktioniert das bei Deinem Aussendienstler eigentlich jetzt prinzipiell nicht mehr oder "nur" bei bestimmten Abfragen ?
Für den erforderlichen Neuaufbau der View-Indizes spricht natürlich viel (Aufbau aller - wenn einer putt ist, misstraue auch den anderen in dieser DB).

Bernhard

Hi Bernhard, mal wieder ein langer Abend überall  <g & seufz>.

Seit dem Fehler hat es der Aussendienstler bisher nicht mehr laufen lassen.  (immer nur abends).

Werde dannn vielleicht morgen früh mehr wissen wobei ich ihm geschrieben habe , in den view zu gehen und shift F9 zu drücken.


Jetzt eine Frage noch:
Weil Du schreibt, ich soll allen views dann mal prinzipiell misstrauen.

das von mir erwähnte strg shift F9 (für alle views) , aktualisiert das nur alle views oder baut es den view neu auf ?

Zweite Frage auch an DIch, kann man das im Programmcode irgendwie checken, ob ein viewindex einen Treffer (lokal Notebook Aussendienst) hat?

Gruß Holcomb

[koehlerbv]

Hi, Holcomb,

ja, die langen Abende ... Ich verbringe die wenigstens in der Regel im Home Office ... Und meist machen sie Spass, aber nur "meist" ...

Ctrl-Shift-F9 baut alle Ansichtsindizes neu auf.

Per Script kannst Du den Zustand eines View Indexes nicht abprüfen.

Auch meine Frage nochmal:

Funktioniert das bei Deinem Aussendienstler eigentlich jetzt prinzipiell nicht mehr oder "nur" bei bestimmten Abfragen ?

Deine letzte Frage mag ich jetzt missverstehen ... Wenn Du nur bei Deinem Aussendienstler wissen möchtest, ob GetDocumentByKey was gebracht hat, kannst Du ja eine Massage-Box einbauen à la
If session.UserName = "CN=Heini Ausserdienst/O=...".

Bin sehr gespannt, wie dieses Rätsel sich lösen wird.

Bernhard

[AC]

Hi Bernahrd,

das mit dem Aussdienstler verstehe ich jetzt auch nicht ganz was Du da meinst.

Kurze Anwendungsbeschreibung, vielleicht bringtd as etwas Licht.

Ausgangspunkt
PDA Anwendung für AD.   Bei uns hat jetzt jeder ADler so ein PDA wo er tagsüber via Barcodescanner und Soll-Istabgleich AUfträge am PDA generiert. Ich hole mir dann die Daten vom PDA aufs Laptop und ins Notes.   Dort haben wir bereits eine bestehende Auftragserfassung im Notes.
Die Kundennummer ist ein eindeutiger Schlüssel und mit deren Hilfe lese ich eben wichtigte Daten im Notes aus.

Zur Sicherheit lasse ich mir temporäre Dokumente in Datenbank 1 erzeugen.
Klappt alles mit den Aufträgen in der Datenbank 2, dann lösche ich diese Dokumente in der 1 wieder, geht was schief, lasse ich die betreffenden Dokumente stehen und weiß dann (nachdem sie repliziert haben), bei welchen docs was schief lief.

Gestern Abend lief ich der eine ADler auf Fehler, obwohl es die male zuvor immer geklappt hat.

Es waren nur zwei Aufträge die er hatte und bei beiden gabs den Fehler. Das würde also auch Sinn  machen, wenn der Index im Eimer ist. Die betreffenden Dokumente die über das getdocumentbykey nicht gefunden wurden, sind aber definitiv in der Datenbank und auch in seiner Replik.  (Er hat auch danach repliziert )

Und als ich hier lokal im Debugger mit seinen Daten nachgespielt habe, hats bei mir funktioniert. (Selbe Verzeichnisstruktur, Rechte etc). Spricht daher auch für Index

Bin mir sehr sicher, daß es sowas wie der Index oder irgend ein anderer Bug gewesen sein muß.


Warte jetzt mal ab, ob es beim nächstem mal bei ihm wieder auftritt oder obd as shift F9 Erfolg brachte.

Wenn ich ihn nochmal ans Telefon kriege, soll er auch zur Sicherheit das von Glombi empfohlene komprimieren des desktops machen und auch mal die cache.dsk löschen.  

Alle anderen Kollegen hatten gestern bei Ihren Aufträgen keine Probleme.


Gruß, Holcomb
 

[Glombi]

Was Du auch noch versuchen könntest, wenn es tatsächlich am Viewindex liegt und ein Shift F9 nichts bringt:
Der Kollege soll eine neue Replik lokal erstellen. Dadruch werden in der neuen Replik erstmal keine Viewindizes angelegt. Er soll dann die alte Replik in ein anderes Verzeichnis sichern (außerhalb des Notes-Datenverzeichnisses, damit er nicht mehr diese DB repliziert).
Die neu angelegte Replik soll er dann an die Stelle kopieren, wo vorher die alte Datenbank war.
Wenn das auch nicht geht, liegt es definitiv nicht am Viewindex.

Andreas

[Rob Green]

hatte so einen Fehler mit getdocumentbykey ... es lag interessanterweise am KFZ Kennzeichen ...

User konnte nach PKWs suchen und wenn ausgewählt, kam der Rest der Daten anhand PKW Bezeichnung.

Passat
Mercedes EKlasse
alles paletti

nicht aber Passat F-MB-9785
das Doc fand die Methode nie

nachdem wir das KFZ Kennzeichen draussen hatten, ging es wieder

Erklärung? Nie eine gefunden. Bei mir ging es nämlich, bei "denen" nicht (klar, gleiche Umgebung 1:1 .. das war also nix).

[AC]

@Bernhard:

Der AD Kollege hat in der betroffenen Ansicht shift F9 gedrückt und dann auch zur Sicherheit nochmal strg shift F9 für alles Views.

Mittlerweile hatte er neue Aufträge (heute morgen auf dem Server reinrepliziert) gefunden und getdocumentbykey hat dann also auch wieder funktioniert.

Problem verursachte also wahrscheinlich defekter viewindex.

@Glombi: desktop lompirmieren haben wir jetzt nicht gemacht, auch nicht die cache.dsk gelöscht.

Aber wenn ich ihn abends bei laufendem Notebook an der Strippe haben , werden wir das mal durchexerzieren.


@Rob. Strange das ganze.

Nochmal danke für die Tips.

Gruß Holcomb