Das Notes Forum

Domino 9 und frühere Versionen => ND7: Entwicklung => Thema gestartet von: Maverick am 24.06.08 - 17:25:23

Titel: Ominöser Type Mismatch - erledigt
Beitrag von: Maverick am 24.06.08 - 17:25:23
Morsche

kann jemand meinem dahinschmelzenden Hirn mal erläutern, warum es in der Zeile Jahr$= zu einem Type Mismatch kommt?

Der Code entstammt einem Agenten der schon seit R4 tadellos läuft. Jetzt erst bemerken wir, dass er seit geraumer Zeit nicht mehr tut. Ich habe da so'ne Ahnung, dass es zeitlich mit der Migration 6 -> 7.0.2 zusammenfällt.

Eines noch, Jahr$ wird vorher nicht dimensioniert.

Dank euch.
Paul
Titel: Re: Ominöser Type Mismatch
Beitrag von: koehlerbv am 24.06.08 - 17:33:54
Die Meldung ist doch blitzsauber: Du weist einen Integerwert einem implizit definiertem String zu. Wenn das kein Type Mismatch ist  ;D

Setz halt ein Cstr vor den Ausdruck.

Bernhard
Titel: Re: Ominöser Type Mismatch
Beitrag von: Maverick am 24.06.08 - 17:51:18
Bernhard,

die Choose rannte über Myriaden von Jahren problemlos.

Why ???

Und macht sich eine implizit definierte Variable den ihr übergebenen Wert nicht so, dass er passt? (OK, hierbei handelt es sich eher um eine Ahnung, als um Wissen)

Paul

Titel: Re: Ominöser Type Mismatch
Beitrag von: MadMetzger am 24.06.08 - 18:26:20
Ja, macht sie, wenn sie ohne implizite Typdeklaration(zB dein "$") da steht. Dann wird die Variable mit dem Typen Variant typisiert und es entscheidet sich erst zur Laufzeit der tatsächliche Typ.

Aber von impliziter Deklaration würde ich (und auch fast alle anderen hier) grundsätzlich abraten, da es solche Fehler schon im Vorfeld verhindern würde.
Titel: Re: Ominöser Type Mismatch
Beitrag von: guesswho am 24.06.08 - 20:21:57
Hallo Paul,

wurde vielleicht heute Nacht 7.03 ausgerollt ?!

Vielleicht hängts damit zusammen  ::)

Wenn du jetzt noch Probs beim Zeilenumbruch von Termineinträgen o.ä. bekommst, guckst du hier: http://atnotes.de/index.php?topic=34105.0. Gilt nur im Zusammenhang mit Umlauten.

notes.ini DisableUniscribe=1 hilft

Jo
Titel: Re: Ominöser Type Mismatch
Beitrag von: Maverick am 25.06.08 - 14:12:41
... Setz halt ein Cstr vor den Ausdruck. ...

Alles, was nur hilft. Dooferweise hat sich die Fehlersituation nicht verändert.

Jahr ist wie erkennbar als String deklariert.

Habt ihr'n Tipp? Danke

Paul
Titel: Re: Ominöser Type Mismatch
Beitrag von: diali am 25.06.08 - 15:05:15
localTime gibt einen String zurück, aber Year() erwartet einen Datum/Zeit-Typ.

Benutze anstelle von localTime LSlocalTime.
Titel: Re: Ominöser Type Mismatch
Beitrag von: Maverick am 26.06.08 - 08:25:05
Das will ich ja gerne glauben. Ich frage mich nur, warum das jahrelang lief.

Weiss jemand etwas von einer Veränderung in 7.xx?

Hier mal ein Beispiel, wie es gerade in einem anderen Forum diskutiert wird:

Zitat
...gestern wurden bei uns die Clients auch auf Version 7.0.3 umgestellt - da hatte ich bei einer Anwendung plötzlich das gleiche Phänomen.
Ursache in meinem Fall war ein Leerzeichen bei dem Befehl "Call uidoc.print (1)". Bis Version 7.0.2 hat das so funktioniert, ab 7.03 muss das "Call uidoc.print(1) heißen...

Gibt es eine halbwegs komplette Liste all dieser Veränderungen?

Danke

Paul
Titel: Lösung
Beitrag von: Maverick am 27.06.08 - 13:41:46
Problem erkannt - Gefahr gebannt

Verarbeitet wurde eine DocumentCollection. Deren erstes Dokument lieferte mit

Dim TimAnfo As NotesItem
Dim dtDokDatum As New NotesDateTime("")
Set TimAnfo = TerminDoc.GetFirstItem("TIMANFODOK")
Set dtDokDatum =TimAnfo.DateTimeValue

den Datumswert dtDokDatum.

Verwendet wurde der Wert localtime für die Anweisung Jahr$ =Year(dtDokDatum.localtime).

Ein einziges Dokument, dooferweise das erste, hatte da "31.12.2007 00:00:00 CET" als Inhalt. Dies schlug fehl. In allen anderen Dokumenten findet sich der Inhalt "31.12.2007". Und mit dem tut es.

Gegenmassnahmen sind eingeleitet. :-) Dank euch, schönes Wochenende.

Paul
Titel: Re: Ominöser Type Mismatch - erledigt
Beitrag von: koehlerbv am 27.06.08 - 13:46:57
Year (TerminDoc.TIMANFODOK (0))

wäre kürzer gewesen und hätte diesen Fehler nicht gebracht, insofern sich in TIMANFODOK ein Date/Time-Wert befindet (was man aber mit Isdate vorab testen kann). Vor allem hätte das die ganzen Typ-Änderungen erspart.

Was sich mir noch nicht erschliesst: Warum wird die Jahreszahl in einem String gespeichert, wo der Rückgabewert doch Integer ist?

Bernhard
Titel: Re: Ominöser Type Mismatch - erledigt
Beitrag von: Maverick am 27.06.08 - 14:18:10
Keine Antwort fällt leichter als diese:

Ich hab keine Ahnung !!!

Es handelt sich doch klassischerweise um ein Stück Code, dessen Urheber längst die Firma verlassen, und um dessen nachträgliche Dokumentation man sich noch keine Gedanken gemacht hat.

Da ich die Anforderungen an das Redesign der DB erst im nächsten Jahr umgesetzt haben muss, schiebe ich das noch ein wenig. Seh's mir nach Bernhard und blicke gnädig auf mein Haupt.

Paul
Titel: Re: Ominöser Type Mismatch - erledigt
Beitrag von: koehlerbv am 27.06.08 - 14:21:41
Ich habe doch gar kein Recht, hier ungnädig zu schauen  :)

Und das
Ich hab keine Ahnung !!!
wird sich ändern, davon bin ich überzeugt.

Bernhard