Problem mit Kombinationsfeld: Datenbanksuche > 65.000 Byte

[semtex]

Hallo mal wieder,
leider habe ich über die Suche nichts wirklich Passendes gefunden, deshalb meine Frage hier:

Ich habe in einer DB eine Maske mit einem Kombinationsfeld. In diesem Feld werden (anhand einer Suche in einer Ansicht) eine ganze Menge von Werten aufgelistet.

Inzwischen hat die Ansicht aber sehr viele Einträge und entsprechend das Kombinationsfeld auch viele Werte. Seit kurzem werden aber nicht mehr die Werte ausgegeben sondern es erscheint die Fehlermeldung: Das Ergebnis der durchfeührten Datenbanksuche umfasst mehr als 65,000 Byte - Notes kann in diesem Fall dieses Ergebnis nicht weiter verarbeiten (siehe beigefügter Screenshot)

Die Auswahl-Formel des Kombinationsfeldes lautet folgendermaßen:

Code

server := "" ;
database := "" ;
view := "Firmen" ;
columnNumber := 1;

Liste := @Unique(@DbColumn(class:"NoCache"; server:database; view; columnNumber));
Liste

Kann mir jemand weiterhelfen, wie ich dieses Problem angehen könnte?

Tausend Dank, semtex!

[koehlerbv]

Das kannst Du nur mit einer Picklist umgehen.

Bernhard

[HH]

Wenn ich das richtig deute, dann gibt es in der Ansicht doppelte Werte, die du mit @unique entfernst. Kannst du statt dessen nicht ein Ansicht bauen, die nach dem gewünschten Feldinhalt kategorisiert ist und den @dbcolumn dann über die kategorisierte Spalte machst?

Hubert

[koehlerbv]

Das ändert aber an der übertragenen Datenmenge nichts - dass das Kategorien sind, sieht man nur im Frontend.

Bernhard

[Glombi]

Ist die 1. Spalte denn kategorisiert? Offenbar nicht, denn Du verwendest ja @Unique.

Das würde ich mal als erstes checken. Falls die Spalte nur sortiert ist, werden auch Massen doppelter Einträge da sein. Durch die Kategorisierung werden nur eindeutige Werte zurückgegeben.

Andreas

[semtex]

@HH / @Glombi: Das mit dem @unique ist nur deshalb, weil es manche (wenige Eintrage) in dieser Spalte doppelt gibt (die unterscheiden sich dann anhand der zweiten Spalte). D.h. es hilf mir leider nicht weiter, die Ansicht zu kategorisieren (oder verstehe ich Dich nicht richtig?).
Trotzdem danke für den Tipp.

@koehlerbv: Das mit der Picklist ist wohl eine gute Idee, allerdings wird das meine bisherige Maske (und entsprechend den "Workflow") über den Haufen werfen.
Falls es noch andere Vorschläge gibt: Her damit!!! 

[Glombi]

Warum eine simple Picklist den Workflow über den Haufen werden sollte musst Du mal erläutern.

Letztendlich wird es doch darum gehen, dass in einem Feld bestimmte Werte stehen. Ob die nun via Kombinationsfeld und @Dbcolumn oder elegant via Picklist gesetzt werden ist doch gehopst wie gesprungen.

Falls nicht, sollte das Design eh über den Haufen geworfen werden 

Andreas

[semtex]

Ok, über den Haufen geworfen ist überzogen, lass es mich so ausdrücken: Es ist eine größere Änderung notwendig, als ich erhofft habe. 
Das mit der Picklist ist auf jeden Fall ein guter Vorschlag, ich hoffe dass ich das auch so hingebogen bekomme, denn die Auswahl im bisherigen Kombinationsfeld hat einige onChange-Aktionen nach sich gezogen. Das soll jetzt aber nicht heißen, dass ich da ein grundsätzliches Problem sehe, sondern eher dass ich da mit meinem Wissen immer wieder an Grenzen stoße.

Ich habe soeben auch nochmal (nur zur Sicherheit) die Geschichte mit der Kategorisierung probiert: Leider sind es, wie befürchtet, immer noch zu viele Einträge in der Ansicht....

Falls es sonst noch Ideen/anregungen gibt, bin ich für alles offen!!!

Danke semtex

[koehlerbv]

Du brauchst doch "fast" nix zu ändern: Das bisherige Feld wird berechnet, und daneben setzt Du einen Buhtong (denn kannst Du auch grafisch gestalten, damit er so aussieht wie die "normale" Auswahlschaltfläche).
Damit bleibt das bisherige Vorgehen (fast) erhalten: Das OnChange verlegst Du einfach ins PostRecalc und stellst beim Feld ein, dass dieses Event getriggert wird bei Schlüsselwortänderungen.

HTH,
Bernhard

[HH]

@Bernhard

Tut zwar nichts mehr zur Sache, aber ich hab das gerade noch mal getestet - mit und ohne Kategorisierung.

Bei gleicher Anzahl Dokument kommt bei Kategorisierung kein Fehler.

Hubert

[Glombi]

@Bernhard

Tut zwar nichts mehr zur Sache, aber ich hab das gerade noch mal getestet - mit und ohne Kategorisierung.

Bei gleicher Anzahl Dokument kommt bei Kategorisierung kein Fehler.

Hubert

Sonst wäre ja auch irgendwas mit dem View Index intern so designed, dass ich es nicht verstehe...

[koehlerbv]

Es kann gut sein, dass ich da gerade eine üble Wissenslücke stopfe bzw. gestopft bekomme. Nur: Kann das jemand sicher bestätigen?

Aber abgesehen davon: Bei grossen Ansichten lebt man als Entwickler immer mit der Gefahr, dass irgendwann auch die reduzierte (Rückgabe-)Datenmenge wieder am Limit kratzt. Und 64 kB sind ja sooo viel nun nicht. Ich präferiere da die grundsätzliche Lösung.

Bernhard

[Tode]

erst mal:
- eine Kategorisierte Ansicht liefert im @DBColumn tatsächlich weniger zurück als eine sortierte
ABER:
Seit R6 spielt das keine Rolle mehr, denn es ist so:
Der DBLookup / DBColumn kann seit R6 MEHR als die 64k zurückliefern, die Grenze existiert nicht mehr.

Warum kommt dann noch die Fehlermeldung, werdet Ihr Euch fragen. In dem Moment wo man mit diesem Ergebnis weiterarbeiten möchte (es also in eine Variable schreibt), kommt man wieder an das Limit, den Variablen haben (genau wie Felder) dieses Limit noch.

ERGO:

Datenmenge[ @Unique( @DBColumn( nichtKategorisierteAnsicht ) ) ] = Datenmenge[ @DBColumn( kategorisierteAnsicht ) ] >>> führt erst dann zu einem >64k Fehler, wenn man dieses Ergebnis einer Variablen zuweist...

Kann man die Datenmenge vorher der Variablen- Zuweisung noch weiter reduzieren, dann kommt der Fehler nicht (in den meisten Fällen geht das aber nicht, weil man ja schon die Spalte so aufgebaut hat, dass sie nur die Werte enthält, die man will).

Trotzdem ein Beispiel:

nehmen wir an, ich habe eine "universelle" Lookup- Ansicht, die so aufgebaut ist:

Vorname~Tido
Vorname~Trude
Vorname~Hans
Nachname~Test
Nachname~Muster
Nachname~Wurst

auch wenn der @DBColumn nun ein Ergebnis >64k zurückliefert, dann KÖNNTE das funktionieren:

Vornamen := @Right( @DBColumn( ... ) ; "Vorname~" )

wenn die Summe der Vornamen wiederum WENIGER als 64k Daten enthält....

Aber als Antwort auf die ursprüngliche Frage kann es nur die "Picklist" geben, denn selbst wenn die Datenmenge temporär so reduziert werden kann, dass die Fehlermeldung nicht mehr kommt, zeigt die Erfahrung, dass in Kürze die Datenmenge wieder so angewachsen ist, dass man wieder an die Grenze stösst.

HTH
Tode

[Untitled]

Ich kann mir auch nicht vorstellen, dass eine Combobox mit so viel Einträgen besonders Benutzerfreundlich ist. Ich denke, die sollte man bis maximal 100 Zeilen verwenden. Anschliessend wird das Scrollen und "bei-klick-daneben-position-verlier" sowieso zu umständlich.

Moritz

[semtex]

Hallo,

ich versuche gerade die Lösung wie oben empfohlen mit der Picklist umzusetzen.
Dabei benutze ich die LS-Funktion PickListCollection().

Allerdings erwartet diese Funktion als Parameter den Server. Den kann ich ja eigentlich dynamisch mit db.server auslesen.
Was passiert nun aber, wenn ich mit einer lokalen Replik meiner DB arbeite? Dann gibt mir db.server einen Leerstring zurück und entsprechend die LS-Funktion PickListCollection() einen Fehler. Kann ich PickListCollection() lokal gar nicht verwenden?

Wie immer schon mal vielen vielen Dank!

Gruß semtex

[koehlerbv]

Die Angabe via NotesDatabase.Server und NotesDataBaseFilePath ist gängige Praxis. Auch lokal darf das keinen Fehler ergeben.

Bernhard

[Tode]

und warum willst Du das unbedingt in Script programmieren ?

in Script sind das 20 Zeilen (minimum), wenn man alles schön deklariert, etc. pepe.

in Formel sind das (jetzt ohne "errorhandling" 2 Zeilen:

ok := @Picklist( ) ;
FIELD abc := ok;

Gruß
Tode

[semtex]

Falscher Alarm:
Ich hatte den DB-Namen unvollständig angegeben. Mein Fehler. 

Natürlich funktioniert es mit db.server und db.FilePath auch lokal.

LS verwende ich weil.... naja, ich die Formelsprache nicht so mag. Ist aber eine persönliche Vorliebe und keinerlei Wertung. Aber wahrscheinlich wäre es in diesem Fall wirklich schneller und kürzer mit einer Formel gewesen.

Danke nochmal an alle für die kompetente Hilfe und "Props" an dieses Forum!
Weiter so!!!

Gruß semtex

[Tode]

persönliche Präferenzen hin oder her...

es gilt (imho) noch immer der Grundsatz (aus Wartungsaspekten, aus Performance- Aspekten, etc....) :

Formel wo möglich (und Sinnvoll), LotusScript wo nötig

Aber egal... ich will hier keine Grundsatzdiskussionen lostreten, ich habe halt nur schon Anwendungen gesehen, die komplett in Script geschrieben waren (vermutlich von einem Umsteiger), die aber eigentlich keine einzige Zeile Script- benötigt hätten....

Gruß
Tode