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?

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

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.

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