Problem mit Datentyp double ab Notes 5.0.10

[jens1979]

Hallo,

ich habe ein Problem mit einer Suche in einer Datenbank.

Bis jetzt benutzten wir Notes 5.0.5 und meine Suche in der DB hat wunderbar geklappt. Mit der Umstellung auf Notes 6 funktioniert sie einfach nicht mehr, bzw. habe ich jetzt mal mit unterschiedlichen Notes Versionen getestet und kann sagen das sie ab Ver. 5.0.10 nicht mehr tut.

Zu meinem Script:

Ich habe eine Ansicht die in der ersten Spalte (Artikelnummer) sortiert ist. Bei dieser Artkilelnummer handelt es sich um ein Zahl Feld. Dieses darf max 10 Zahlen lang sein. Da mir in meiner Suche mittels LotusScript hier der Datentyp Long nicht ausgereicht hat, habe ich Double verwendet.

Also einfach mit doc = view.GetDocumentByKey(DoubleVariable).

Ab Notes 5.0.10 bleibt meine Variable doc allerdings leer, wenn ich hingegen die DoubleVariable gegen Long austausche funktioniert alles wunderbar ... solang halt keine Artikelnummer über 2147483647 kommt.

Also weis irgendjemand woran das liegen könnte bzw. wie ich das ganze fixen kann ... ich verstehs nicht mehr.

Danke schonmal

Jens

[mahonri]

Warum machst du das ganze nicht mit Text?
Wenn du den Wert unbedingt als Zahl brauchst, kannst du ihn in der Ansicht als @Text(Wert) darstellen und auch von Script aus als Text suchen, dann solte es keine Probleme mehr geben oder?

[TMC]

@Mahagoni:

Warum machst du das ganze nicht mit Text?

Generell sollte man immer den kleinstmöglichen Datatype nehmen. Bei 10 Stellen liegt daher Double auf der Hand.
Und das hört sich für mich wirklich nach einem Bug an. Workaround wäre wohl wirklich, auf ein String auszuweichen.

@Jens:
Ich hatte auch schon manchmal Probleme mit GetDocumentByKey (allerdings ohne wissentlichen Zusammenhang mit Double-Datentyp).

Was evtl. helfen könnte:
 - Ist wirklich nur die 1. Spalte sortiert? Falls nein: nimm mal die Sortierung bei den Folgespalten raus.
 - Ist die erste Spalte kategorisiert? Wenn ja/nein: Probiere es mal anders herum.

Und schau auch mal in der Knowledgebase nach, ob der Issue bekannt ist.

[koehlerbv]

Die Knowledgebase hatte ich deswegen auch schon durchforstet. Niente. Sacht nix, das gute Teil.
GetDocumentByKey in Ansichten mit einem skalaren Key, bei denen mehrere Spalten sortiert waren: Hatte ich noch nie ein Problem.

A-Bär: Wenn die App bisher lief und erst ab 5.0.10 'rumzickt, ist das eindeutig ein Bug (vor allem, da Long ja noch funktioniert).

Mahonri's Vorschlag sollte aber ganz leicht zu folgen sein - es erfordert ja nur zwei klitzekleine Umstellungen.

Mir selbst ist sowas bisher in diesem Zusammenhang noch nie passiert: Bei mir sind sowas wie Artikelnummern immer alphanumerisch abgelegt. Die Dinger sehen im Idealfall aus wie eine Zahl, aber dann kommt doch jemand auf die Idee, dass doch viel schöner wäre, vorne führende Nullen anzuhängen oder die Artikelgruppe über einen dreibuchstabigen Kenner davorzusetzen oder ... Das Handling bleibt ja absolut identisch - ausser, dass man nicht so eingeschränkt ist. Selbst der Ziffernblock taugt bei reinen Zahlen noch alleine zum Einhacken ...

Bernhard

[TMC]

Das stimmt allerdings, Bernhard, die Gefahr ist z.B. bei Artikelnummern sehr groß, dass jemandem einfällt, da noch Buchstaben etc. irgendwann mal zu integrieren.

Trotzdem würde mich interessieren, warum der Double-Datentyp zickt  

Zu mehreren sortierten Spalten & GetDocByKey: Ich hatte da in der Tat schonmal Probleme - er fand mir teilweise nicht immer ein Dokument. Nahm ich die weiteren Sortierungen raus, dann klappte es.
Wobei - eigentlich ist das ja auch eine Performancebremse - je mehr Spalten sortiert werden. Und für GetDocByKey nehme ich eh immer hidden views - d.h. eine Sortierung (also der 1.Spalte) reicht ja für eine GetDocByKey-View.

[koehlerbv]

Mit den Artikelnummern (und anderen wie Patientennummern, Antragsnummern und was für Nummern die Leute noch so schieben ;-) habe ich schon Dinge erlebt ... Ohne Worte ! Da kommt mir nur was alphanumerisches ins Haus. Wie gesagt: Der Effekt ist ja absolut identisch. Selbst rechnen könnte man ja noch damit (durch DataType-Wandlung, ggf. vorher Parsing), wenn jemand zum Beispiel in der dritten Stelle der NUMMER seine Rabattierbarkeit hinterlegt ;-)

Interessieren würde mich auch, was da 5.0.10 treibt. Muss ja ein Bug sein.

Je mehr Spalten sortiert sind, desto mehr Performanceeinbruch (nicht bei GetDocumentByKey, sondern bei der Ablage neuer oder modifizierter Dokumente). Deshalb sollten Deine Tips, Matthias, unbedingt immer beachtet werden:
- Genau die Spalten sortieren, die erforderlich sind - niemals mehr.
- Für programmatische Zugriffe IMMER UND NUR versteckte Ansichten verwenden. Und diese so simpel wie möglich aufbauen -sieht ja eh "keiner". *)

Allerdings könnte es durchaus erforderlich sein, das man für GetDocumentByKey mehrere sortierte Spalten braucht (ich arbeite damit auch oft) - man kann glücklicherweise auch über ein Array als Key suchen.

Bernhard

*) Warum versteckte Ansichten: Was der Anwender sieht, mag er oft verändert wissen. Fix ist da sowas da wie "In der ersten Spalte brauchen wir aber noch das Erstelldatum, und danach soll wahlweise bei Klick auf die Spaltenüberschrift sortiert werden können. Wenn darauf jetzt ein @dbLookup oder ein GetDocumentByKey basiert - Prost Mahlzeit.

[TMC]

joo, kann ich nur bestätigen, dass man für programmatische Zugriffe ausschließlich Hidden Views verwenden sollte.

In Notes haben wir es ja bei den Datentypen noch überschaubar. Der mit R6 neue Datentyp Boolean passt da auch noch gut dazu (wobei es da Integer auch tut, um True/False zu definieren).
Richtige Probleme haben Kollegen mit relationalen DBs, wo es wohl gang und gäbe ist, Strings immer auf wenigste Stellen zu reduzieren. Wenn da dann der Anforderer kommt, und will das für ein Feld erweitert haben: gute Nacht (oftmals zig Abhängigkeiten zu diversen Tables, etc. etc.).

[koehlerbv]

Was man immer wieder betonen sollte, Matthias, wenn mal wieder so ein Komiker mit "Notes ist (anderes Wort für Exkremente) daherkommt und auf RDMS schwört. Alles, wo es hinpasst. Alles mit seinen Risiken und Nebenwirkungen.
Das Datatype conversing in Notes ist einfachst, verleitet natürlich auch zu Fehlentscheidungen. Aber wenn man weiss, was man tut ... Genial !
By the way: True or False kann man neben Boolean (R6+ only) und Integer auch als Single, Long oder Double, gar Currency darstellen.

Servus,
Bernhard