Kryptische Fehlermeldung in Maske

[Li Si]

Hallo Notes-Spezis,

seit einiger Zeit taucht beim Starten einer Maskenaktion in meiner Datenbank immer wieder der folgende Fehler auf:
"Falscher Datentyp in Methode CoerStrToNum: STRING wurde gefunden, LONG wurde erwartet".

Leider taucht dieser Fehler nur sporadisch auf, und ich selbst habe ihn noch nicht reproduzieren können.

Meine Recherchen hier und in den Weiten des I-Net haben ergeben, dass das die charmante Art von Notes 8 ist, einem mitzuteilen, dass es irgendwo im Code einen Syntax-, Schnittstellen- oder ähnlichen Fehler gibt. Allerdings anscheinend sehr unspezifisch.

Hat jemand eine Idee, wie ich der Sache auf die Schliche kommen könnte? An die Personen, die den Fehler erhalten, komme ich leider nicht ran, da es sich um die Kunden meines Kunden handelt.

Bin für jeden Tipp dankbar!
Li Si

[Axel]

Die Meldung könnte z.B. dann auftreten, wenn auf ein noch nicht gefülltes Zahlenfeld eines neuen Dokumentes zugegriffen wird.

Wie sieht denn der Code von CoerStrToNum aus?

Axel
 

[Li Si]

Wenn ich das wüsste  
Die Meldung scheint irgendwo aus den Tiefen der Notes-Basis zu kommen und hat wahrscheinlich mit dem eigentlichen Fehler nicht viel zu tun...

Es handelt sich tatsächlich immer um ein neues Dokument, die Maske wird nur zum Erstellen verwendet. Allerdings besitzt die Maske nur ein einziges Zahlenfeld, und der Fehler tritt auch auf wenn dieses Zahlenfeld ordnungsgemäß gefüllt ist, bzw. auch wenn ich das Zahlenfeld nicht fülle funktioniert bei mir alles einwandfrei  

[Peter Klett]

http://www-01.ibm.com/support/docview.wss?rs=463&context=SSKTMJ&dc=DB520&dc=DB560&uid=swg21303181&loc=en_US&cs=UTF-8&lang=en&rss=ct463lotus

Was passiert in der Maskenaktion? Ist die in sich abgeschlossen oder führt die noch weitere Aktionen in dem Dokument aus, z.B. ein Refresh oder uidoc.Save. Dann kann der Fehler auch aus anderen Script-Events der Maske (z.B. Postrecalc, Querysave) kommen.

[pram]

Dieser Fehler kann auch auf fehlerhaften, bzw nicht passenden Object-Code hindeuten.
Ein Recompile all oder das Neucompilieren * der Maske könnte das Problem lösen.
(Dass in den Script-ibraries / Masken ein "Option Declare" steht nehme ich jetzt mal an)

*) Der 8.5.1er Designer compiliert mache Designelemente nicht mehr sauber beim Recompile all:
http://www-10.lotus.com/ldd/beta/nd80xbetas.nsf/5f27803bba85d8e285256bf10054620d/4aa4231f178ed9db852576c50044215c?OpenDocument
Dazu in den LS-Teil des Elements rein gehen, irgendwo eine Leerstelle rein machen und wieder löschen und neu speichern.

Gruß Roland

[Li Si]

@Peter
Danke, ja, die TechNote hatte ich auch schon gefunden. Und ja, die Maskenaktion macht ein doc.Save, was die Fehlersuche nicht gerade vereinfacht, denn damit kann der Fehler ja auch in einem Feld-Event o.ä. liegen...

@pram
Danke für den Tipp, allerdings habe ich erst kürzlich Script-Code in der Maske geändert, wieder rückgängig gemacht und die Maske neu ausgerollt. Leider hat das nicht geholfen 
Oder werden solche "Pseudo-Änderungen" evtl. gar nicht mit ausgerollt und ich müsste tatsächlich etwas ändern, damit der neu kompilierte Code auf der Produktion landet?

[Peter Klett]

Wenn das doc in doc.Save ein NotesDocument ist und kein NotesUIDocument, dann kann es kein Feld-Event sein, da beim Speichern im Backend diese Events nicht ausgeführt werden.

[BigWim]

Hat jemand eine Idee, wie ich der Sache auf die Schliche kommen könnte? An die Personen, die den Fehler erhalten, komme ich leider nicht ran, da es sich um die Kunden meines Kunden handelt.

Vielleicht habe ja die Dimensionen dieses Problems nicht erkannt, aber nach meinem Verständnis:

1. Die "fehlerbehaftete" Funktion ist bekannt. Die wird im Speicher-Prozess wahrscheinlich mehrmals aufgerufen.

2. Da der Fehler sporadisch auftritt, werden "unerwartete" Parameter übergeben. [OT]Ein mir sehr bekanntes Problem: Auf was für Ideen die User kommen ...[/OT].

3. Folglich benötige ich das Dokument, in diesem Zustand. Also würde ich - laienhaft ausgedrückt - daran interessiert, an dieses Dokument zu kommen, notfalls die Ursprungswerte des Dokuments zu kennen.

4. Das würde ich über ein OnError in dieser Funktion versuchen, die beim Auftritt dieses Fehlers, z. B. das Dokument kopiert per CopyAllItems?, die ein Flag setzt, um zumindest mal das Dokument identifiziert?, ....

Wenn diese Ausführungen auch nicht das Gelbe vom Ei ist, hoffe ich doch mal, dass es neue Ansätze liefert.

Viel Erfolg
Markus

[Li Si]

@Peter
Stimmt, es ist natürlich ein uidoc.Save und kein doc.Save! Sorry! 

@BigWam
Die Idee ist nicht schlecht, in diese Richtung werde ich mal weiterdenken. Danke!

Weiß jemand, ob es automatische Protokolle gibt, in denen ich evtl. Infos zu solch einem Fehler finden könnte, wenn ich weiß von wem und zu welchem Zeitpunkt er verursacht wurde?

[Axel]

Automatische Protokolle gibt's nicht. Dafür musst du selbst sorgen, z.B. durch entsprechenden Meldungen in einer Protokoll-Datenbank. Schau dir dazu mal die Klasse NotesLog an.

Axel

[pram]

Hallo Li Si,

das Problem trat bei mir meist dann auf, wenn eine Maske eine Library "used" und in der lib was geändert wird (z.B. zusätzliche Methode in der Klasse), dann ist die Maske immer noch gegen die alte Klassensignaturen compiliert und es treten die komischsten Fehler auf( General LSE Error, oder eben der den du beschreibst)

Ein Recompile all oder ein Neuspeichern der Maske (wobei man aber im LS-Code was änder muss, deshalb Leerstelle hinzufügen) löst einen Recompile aus, wobei die Maske dann gegen die neue Lib compiliert wird.

Besonders "fies" ist der 8.5.1er Designer, da dieser TEILmasken beim Recompile-All nicht mehr mitcompiliert.

Hast du denn eine Zeilennummer an der der Fehler auftritt? (->Errorhandler oder Debugger)
Falls die Zeilennummer unplausibel ist (weil z.B. ein der Zeile kein solcher Fehler auftreten kann) denke ich dass ich mit meiner Vermutung richtig liege. Allerdings spricht dagegen, dass der Fehler nur sporadisch auftritt (evtl gibts auch die Maske 2x mit selben Namen, dass hin und wieder die "defekte" verwendet wird)
Ansonsten musst halt mal schauen, was der User da eingibt, wenn der Fehler auftritt.

Gruß aus Italien 
Roland

[Li Si]

So, ich habe jetzt mal ein Errorhandling eingebaut, das bei Fehler das Dokument kopiert und als "Fehlerdokument" in der DB abspeichert. Zusätzlich werden in dem Fehlerdokument Fehlertext, Fehlernummer und Fehlerzeile abgelegt.
Mal sehen, ob mich das weiterbringt - ich halte euch auf dem Laufenden.

Von einem Kollegen bekam ich heute noch den Tipp, dass ähnliche Fehler entstehen können, wenn in einem bearbeitbaren Feld Script-Events gefüllt sind und das Feld anschließend in ein berechnetes Feld umgewandelt wird, ohne den Script-Code zu löschen. Der Script-Code wird dann zwar nicht mehr angesprungen, kann aber Probleme beim Kompilieren verursachen. Das war bei mir nicht der Fall, aber vielleicht hilft es ja jemand anderem.

@Axel
Danke - das "Logging" erledige ich jetzt über das Fehlerdokument.

@pram
Es gab zwischendrin auch mal einen General LSE Error (der ist inzwischen ein guter Bekannter von mir  ) in der Datenbank, den ein Recompile All beseitigt hat. Für den hier diskutierten Fehler hat das leider gar nichts gebracht.
Teilmasken gibt es nicht in der fraglichen Maske, und die Maske ist auch nur einmal in der Datenbank vorhanden.
Ob mir die Fehlerzeile weiterhelfen wird, werden wir sehen...
Vielen Dank für deine Überlegungen!

[Li Si]

Leider bin ich noch nicht wirklich weiter in der Sache - die Fehlerdokumente die ich erhalten habe melden tatsächlich einen Type Mismatch, wann und wo der auftritt konnte ich aber immer noch nicht klären. Klar ist denke ich dass es etwas mit den Eingaben des Users zu tun haben muss, da der Fehler ja nur ab und zu mal auftritt. Reproduzieren konnte ich ihn aber immer noch nicht, trotz 1:1-Kopien der fehlerhaften Dokumente...

Ich melde mich wenn ich Neues weiß!

Grüße aus Lummerland 

[Axel]

Dann bau doch mal an allen Stellen an denen Benutzereingaben erfolgen entsprechend detaillierte  Meldungsausgaben in die Protokolldatenbank ein. Dann solltest du relativ schnell erkennen können wo's klemmt.

Axel

[Li Si]

Gibt es in Notes eine Möglichkeit, außer Fehlernummer, Fehlertext und Fehlerzeile (also Erl, Error und Err) weitere Infos zu einem Fehler zu bekommen? Die Fehlerzeile nutzt mir ja leider wenig, wenn ich nicht weiß in welchem Script genau der Fehler aufgetreten ist. Kann ich irgendwie an den Namen des aktuell laufenden Scripts kommen?

@Axel
Wie meinst du das? Es handelt sich ja um eine Maske mit diversen Eingabefeldern. Nach dem vollständigen Ausfüllen der Maske startet der User ein Script, das eine Validierung durchführt, einige interne Änderungen am Dokument vornimmt und dann im Frontend speichert.
Welche Stellen würdest du für Meldungsausgaben für geeignet halten?

[TRO]

ja, da gibt es einiges undokumentiertes mit "LSI_Info".

Kannst mich ja mal in BLN anrufen.

hth

Thomas

[Axel]

@Axel
Wie meinst du das? Es handelt sich ja um eine Maske mit diversen Eingabefeldern. Nach dem vollständigen Ausfüllen der Maske startet der User ein Script, das eine Validierung durchführt, einige interne Änderungen am Dokument vornimmt und dann im Frontend speichert.
Welche Stellen würdest du für Meldungsausgaben für geeignet halten?

Ohne das Script zu kennen ist das äußerst schwierig. Aber ich würde zum Beispiel bei der Validierung ansetzen und evt. bei den internen Änderungen. Ich würde mir auch die Eingabefelder protokollieren lassen. Lieber zuviel protokollieren als zu wenig.

Axel

[koehlerbv]

Das ist ein spannendes Thema und komplett neu mit Notes 8. Die Meldung ist Bullshit und vollkommen nichtssagend - und war in den Fällen in 8.0er Versionen, in denen ich sie erlebt habe, bislang immer ab 8.5 gefixt (was nun aber noch kein Beweis ist). Wurde der Code mit 7.0x oder früher ausgeführt, trat der "Fehler" ebenfalls nicht auf. Und ja - es immer ein "Zusammenspiel" zwischen Front- und Backend, dass der 8.0er Client (und klar - das könnte partiell im 8.5er auch noch stecken) nicht mehr versteht. Insofern gehen nahezu alle Aussagen hierzu ins Leere (auch, was das Debugging angeht, und das wäre versionsunabhängig).

Ich mag jetzt aber nicht in meinen "Niederschriften" hierzu suchen, weil mit "Li Si" kann ich nun gar nichts anfangen. "Li Si" muss Punkt 2.2 der Forumsregeln nicht dahingehend auslegen, dass zumindest ein ansprechbarer Vorname angegeben werden muss. Und ich habe kein "Muss", hier Beispiele auftretender gleicher oder ähnlicher Fehler, die betroffenen Versionen und vor allem ggf. Lösungen zu posten.

Bernhard

[BigWim]

Welche Stellen würdest du für Meldungsausgaben für geeignet halten?

Ohne das Script zu kennen ist das äußerst schwierig. Aber ich würde zum Beispiel bei der Validierung ansetzen und evt. bei den internen Änderungen

Wenn Du 1:1 Kopien der Dokumente hast, mußt Du den Fehler nachstellen können, ansonsten suchst Du an der falschen Stelle.

Ansonsten hat Axel alles mögliche gesagt: Wie auch immer Dein Script aufgebaut ist, Du mußt in jedem Fall die Eingaben des Users wegschreiben.

Ich will nicht ausschließen, dass es elegantere Möglichkeiten gibt, aber ich würde mit einer Liste arbeiten, die die möglicherweise relevanten Felder listet und bevor das Script seine eigentliche Aufgabe beginnt, in einer Schleife dieses Liste abarbeiten, die Feldinhalte in neue Items (ursprüngliche Name + Endung "_D" für Debug zum Beispiel) kopiert.

Markus

[bluenotemk]

Hallo Zusammen,

Auch wenn das Posting schon alt ist:
Ich habe die gleiche Fehlermeldung bekommen, wenn ich angenommene Einladungen aus dem Maileingang gelöscht habe. Auslöser war, dass es unter "Vorgaben -->Kalender und Aufgaben -->Autom. verarbeiten eine Option gibt, die entweder auf "Löschvorgang bestätigen" oder "Aus dieser Ansicht...entfernen" stehen muss. In meinem Fall war der Eintrag leer, was offenbar nicht vorgesehen ist.

Wahrscheinlich sind die Umstände, wo es bei mir auftrat anders aber vielleicht könnte man grundsätzlich folgern, dass irgendwo ein Optionsfeld leer ist, obwohl ein Wert verpflichtend ist.


Bis denne