Domino 9 und frühere Versionen > ND8: Entwicklung

Fehler beim löschen von privaten Ansichten

(1/2) > >>

Legolas:
Hallo Forum,

ich habe das Problem, dass ich private Views von Typ "Gemeinsam, privat bei Erstbenutzung" auf dem Server nicht mehr löschen kann.
Ich selbst habe Manager Rechte auf die Anwendung.
Beim Löschen direkt im Designer kommt folgende Fehlermeldung: "Eintrag nicht in Gestaltungsliste" (Siehe Bild1)
Versuche ich die View per Script zu löschen, wird folgende Fehlermeldung geworfen: "Notes-Fehler: Index kann auf dem Server nicht erstell werden" (Sieh Bild 2)

Die privaten Ansichten können gelöscht werden, solange keine Änderung des Selectstatements vorgenommen wurde.
Solange das ursprüngliche Select-Statement eingetragen ist, funktioniert alles bestens.

Die User können sich jedoch individuell das Select-Statement für ihre private View über einen Dialog zusammen klicken.
Per Script wird dann dieses Select-Statement in der privaten View geschrieben. Was auch soweit funktioniert.
Die private View stellt dann den gewünschten Inhalt auch dar!

Nur kann im Anschluss (nach einer manuellen Änderung des Select-Statemant) die private View nicht mehr gelöscht werden was zur Folge hat, dass keine Design-Updates usw.
mehr durchgeführt werden können.

Kennt jemand eine Lösung für das Problem?

Grüße
Legolas



Umgebung
Domino 8.5.3 FP1 englsich
Notes 8.5.3 FP1 deutsch

koehlerbv:
An private Ordner und Ansichten kommst Du zentral eh nicht (sicher) ran. Wenn dann noch ein (versehentlicher) Eintrag in der ACL steht, dass der User in der DB gar keine privaten Elemente angelegt werden, geht das halt eben doch - aber gespeichert wird im lokalen Desk-Topf. Dann ist endgültig der Krieg verloren.

Ich führe für derartige Elemente zentrale und userbezogene Einstellungen in den Anwendungen. Ändert sich die zentrale Versionsnummer bei einem Update und die persönliche ist nicht entsprechend, wird dem User ein Update angeboten. Das läuft dann (bei "Jo, mach ma!") im Kontext lokal beim User, das private Designelement wird gemeuchelt und wird beim erneuten Öffnen der DB neu erzeugt.

HTH,
Bernhard

Legolas:
Moin Bernhardt,

danke erst mal für die Rückmeldung.
Ich glaube wir reden allerdings von zwei verschiedenen Dingen.

Ich kann nach einer programmatischen Änderung des Select-Statements eine private View gar nicht mehr löschen bzw. das Design ändern.
Wenn ich mir die Eigenschaften im Designer anzeigen lasse, hat diese einfach keinerlei Einträge mehr.
Daher kommen auch die Fehler die ich gepostet habe.
Das Problem ist reproduzierbar.

Bei mir geht's so:
1) Ein View-Template erstellen, dass als Eigenschaft "Gemeinsam, privat bei Erstbenutzung" besitzt. (Im Designer das Symbol Schlüssel mit einer 1)
2) Dieses View in der Anwendungs-UI aufrufen.   --> (Es wird eine View erzeugt, die als Symbol im Designer nur einen Schlüssel besitzt. Die Eigenschaften wie $Flag usw. sind im Designer vorhanden und die View kann auch wieder gelöscht werden.
3) Das Selectstatement dieser View mit z.B. dem folgenden Code per Agent verändern:
Ansichtsinhalt wird dann korrekt laut neuer Selectionsformel angezeigt!


--- Code: --- Dim ws As New NotesUIWorkspace
Dim ses As New NotesSession
Dim db As NotesDatabase
Dim Doc As NotesDocument
Dim view As NotesView
Dim selString As String

Set db = ses.currentdatabase
Set view = DB.Getview("PrivByAccount")
If view Is Nothing Then
MsgBox "view nicht gefunden!" , 16, "Hinweis"
Exit Sub
End If

selString = ws.Prompt(3, "SELECT", "Neuer select: ", "",selString)
If selString = "" Then
Exit Sub
End If

view.Selectionformula = selString
Call ws.Reloadwindow()

--- Ende Code ---

3) Im Designer sich die Eigenschaften dieser View nun anzeigen lassen! Diese sind nicht mehr vorhanden.
--> Die View kann auch nicht mehr gelöscht werden. Weder im Designer noch programmatisch.
Solange keine Manipulation des View-Selectstatements vorgenommen wurde, sind die Eigenschaften vorhanden und die View kann gelöscht werden.

Anmerkung:
Ich hatte bisher diese Anwendungssituation über Ordern abgebildet.
Das Problem ist allerdings, das es inzwischen teilweise mehrere Tausend Dokumete sein können und die User immer wieder
vergessen, die Ordner zu aktualisieren.
Die Aktualisierung dauert natürlich dann auch noch einige Sekunden usw.
Mit einer View die der User individuell mit einem Selektstatement belgen kann, wäre das Problem für alle Zeit behoben.


Grüße
Bernd

Tode:
Private Views sind IMMER ein "pain in the a....".

Wenn ich so ein Konstrukt brauche, dann baue ich mir die "Private view" als "normale" view nach (mit einem Unique- namen pro Benutzer, z.B. per @Name( [TOKEYWORD] ; @UserName ) oder per Zuweisung in einem Profil- Dokmument @UserName = ViewName_Für_Diesen_User).

Per Script ist es kein Problem, eine View mit einem "Template" zu erstellen.... Es handelt sich dann um eine Ansicht, die ich als Designer immer Kontrollieren / manuell löschen kann (kein $Readers- Feld), und die auch beliebig manipulierbar ist.

Mit Private- Views bin ich schon so oft auf die Schnauze gefallen, dass ich die einfach nicht mehr verwende...

Legolas:
Moin Tode,

das funktioniert aber nur so lange, wie du "statische" Select-Statements hast und eine überschaubare Zahl von Usern.  ;)
Wenn der User aber selbst wählen kann was er sehen will, wird das nicht mehr gehen.
In meinem Fall können die User die Attribute für das Select-Statement selbst wählen. (Siehe Bild 3)

Grüße
Bernd

Navigation

[0] Themen-Index

[#] Nächste Seite