SELECT(@Contains(vrrAutor;@Name([CN];@UserName)) | @Contains(vrrFreigabePersonDisp;@Name([CN];@UserName)) | @Contains(vrrAdressatenGruppeDisp;"&V13_VRR_TR-Info_Admin") | @Contains(vrrAdressaten;@Name([CN];@UserName))) & (vrrDocStatus != "Papierkorb" | @If((vrrFreigeben != "" & vrrFreigabe = "Ja")) & (Form = "vrrfrmNeuesDokument")& (vrrGueltigkeitDatum="" | vrrGueltigkeitDatum>=@Date(@Now)) | @AllChildren)
Hi Mirko ...
Wenn das jemals funktioniert haben sollte was mit dem Select in dieser Anwendung getrieben wird, dann kann das nur Zufall gewesen sein. Zumindest wenn ich von deinen bisherigen Informationen ausgehe.
Siehe Online Hilfe zu @UserName ...
Usage
When a formula runs on a server, the agent signer is considered the current user. Using @UserName on a local database or in a private view in a server-based database returns the user's name. You should not use @UserName in a public view, doing so produces unpredictable results. Also, if the field that you are referencing changes, you will get unpredictable results because the index has to be rebuilt to accommodate the new information.
One use for @UserName is to display only those documents relevant to the current user. For example, your Service Request database could use @UserName in the private view named Assignments to display each technician's assignments, weeding out everyone else's:
SELECT @UserName=AssignedTo
However, the user can still design a different private view that retrieves all documents, so don't depend on @UserName as a security mechanism.
Also das kann nur funktionieren wenn das in "private" Views eingebaut wurde.
Dann will ich aber nicht wissen wieviele Benutzer die Datenbank hat. Und schon gar nicht, ob irgendjemand sich Gedanken über die Update Mechanismen die hinter Private Views liegen MÜSSEN, wenn jemand den Source für das Ding verändert, gemacht hat.
