Hilfestellung- Schulung

    • Offizieller Beitrag

    ok und abwohl DU einen Namen auswählst kommt in dem ersten Prompt nix?, dann übergibst Du das falsche Feld.


    Der Prompt
    @Prompt([OK]; "Wert @Name(...)"; @Name([Abbreviate]; Username));
    zeigt Dir den Schlüssel / key an, der an den DBLookup übergeben wird und da muss nun mal was drin stehen. Vergleiche noch einmal den Feldnamen in der maske mit der Schreibweise des Feldnamen im @DBLookup.


    Gruß
    Dirk

    Hallo Dirk,


    mein Chef hat angerufen wie weit ich bin, habe Ihm dann gesagt was los ist wo ich hänge, habe Ihm dann die Db geschickt und er hat es sich angesehen und mir folgende Lösung gezeigt.
    Er hat mir also nicht den Kopf abgerissen oder mich zur Schnecke gemacht. Habe Ihm womöglich Unrecht getan.


    Beim Feld Username steht das im Vorgabewert:


    name := @Name([CN]; @UserName);
    @Right(name; " ") + " , " + @Left(name; " ")


    Bei Eingabeumsetzung steht das:


    name := @Name([CN]; UserName);
    @If(@Contains(username;"/");@Right(name; " ") + " , " + @Left(name; " ");username)


    Im Feld TelNr steht das:


    key:=username;
    @DbLookup("": "No Cache"; "degdf06":"names.nsf"; "People"; key; "OfficePhoneNumber")


    Ausserdem hat er bei den Eigenschaften der Felder noch was geändert.


    Werde morgen früh gleich die anderen Felder der Maske anpassen.
    Bevor dann die nächsten Probleme, Schwierigkeiten für mich kommen. Denn das war ja wahrscheinlich erst der "einfachere Teil der Anforderung.


    Danke schon mal für Hilfe und Geduld.
    Hoffe ich darf dich wieder belästigen.


    Michaela

    • Offizieller Beitrag

    oh oh nicht gut
    @Right(name; " ") + " , " + @Left(name; " ")


    Es wird versucht der Vorname und Nachname zu tauschen. Dabei wird ein Leerzeichen als Trenner vermutet. Was ist mit Namen wie "Max aus dem Walde" und "Max Moritz Müller"? Da geht der Code in die Hose!


    Gruß
    Dirk

    Oh oh,


    da bin ich gespannt, es gibt ein paar bei uns mit Doppelnamen.


    Mal sehen. Eigentlich bräuchte ich eh nur den Nachnamen, da es für den Vornamen ein eigenes Feld auf der Maske gibt.


    Auf alle Fälle hat er das gleiche gesagt wie Du ,es muss ein Name vorgegeben sein, sonst funkt es nicht.

    Wow ... 100 Postings für einen kleinen Knopf.


    Und dann noch einen Chef, der etliche Leute (hier im Forum) bis zur gefrusteten Aufgabe beschäftigt obwohl er scheinbar selbst in der Lage ist, in wenigen Minuten das Problem zu lösen und dir einen Ratschlag hätte geben können. Das einzige, was mich dabei wieder etwas grinsen läßt ist die Tatsache, daß dein Chef dann sooo viel Ahnung doch nicht hat, da er ein paar simple Programmier-Regeln nicht beachtet hat und die Sache obendrauf viel zu kompliziert angeht.


    Ich lasse jetzt mal jegliche weitere Bemerkung zur Sinnhaftigkeit einer "Schulung" auf diese Art und Weise sein und beschränke mich einfach auf ein paar technische Bemerkungen.


    Punkt 1) Herangehensweise mit @DbLookup


    Die hier aufgezeigte Lösung hinkt gewaltig, sowohl in der Variante der Forenmitglieder als auch der "Chef-Version".


    Es sind mehrere potenzielle Fehlerquellen enthalten, hauptsächlich wurden aber 2 simple Regeln für den angehenden Programmierer ausser Acht gelassen:


    Regel1: Niemals ein @DbLookup oder @DbColumn ohne Fehlerbehandlung einbauen!


    Wenn schon mit den beschriebenen Formeln dann bitte den Rückgabewert noch mit @IsError abfangen (siehe Noteshilfe). Das sähe dann in etwa so aus:

    Code
    _ergebnis := @DbLookup("": "No Cache"; "degdf06":"names.nsf"; "People"; key; "OfficePhoneNumber");@If( @IsError( _ergebnis ); ""; _ergebnis)


    Mit dieser Änderung würde eine fehlerhafte Suche schlimmstenfalls einen leeren Wert liefern. Ohne diese Behandlung gibts eine schöne Meldung, meistens ist das "Eintrag im Index nicht gefunden".


    Regel2: Niemals @DbLookups auf für Endnutzer sichtbare Ansichten programmieren


    Ansichten, die für Endnutzer sichtbar sind, unterliegen gern Änderungen. Angefangen von "Kann man das nicht anders nennen" über "ich änder mal die Sortierung" bis hin zu "ich brauch da aber noch eine Spalte da ganz links". Im konkreten Fall hat die Personen-Ansicht zwar schon seit Jahren diese Darstellung mit "Nachname <Leerzeichen> <Komma> <Leerzeichen> Vorname" aber ich würde auf diese Darstellung nicht wetten. Mal ganz abgesehen von den bereits angesprochenen Problemen mit Doppelnamen etc. wo die Suche deines Chefs mörderisch in die Hosen geht.


    Hier wäre eine versteckte Lookup-View deutlich sinnvoller. Da es sich um das Dominoverzeichnis (names.nsf) der Domäne handelt lasse ich den sonst üblichen Best-Practice-Vorschlag mal sein, eine spezielle View dafür zu hinterlegen (obwohl ich es ggf. in Betracht ziehen würde). Sinnvoller wäre hier die View $Users, die als Nebeneffekt sogar alle Schreibweisen der Namen, nämlich vorwärts, rückwärts, mit Schrägstrichen usw. usf. schon beinhaltet.


    ABER und damit kommen wir zu


    Punkt 2) Verhältnismäßigkeit der Mittel wahren


    wie eingangs erwähnt finde ich zumindest für die hier angesprochene Funktion den ganzen Aufwand mit @DbLookup, Feldzuweisung und Fehlerbehandlung reichlich übertrieben.


    Auch wenn ein erfahrener Programmierer gern mal mit Kanonen auf Spatzen schießt...es gibt einen deutlich einfacheren und leichter zu verstehenden Weg zu deinem angesprochenen Ziel:


    Ich würde zuerst die Namensauswahl nicht über einen Knopf (Button) sondern einfach 1 bearbeitbares Feld vom Typ "Dialogfeld" mit der Auswahloption "Adressdialogfeld" und "Felder bei Schlüsselwortänderung aktualisieren" in die Maske nehmen, wo der Nutzer den Namen auswählen kann. Nennen wir es halt wie in deinem Beispiel USERNAME (auch wenn ich den Namen nicht so toll finde, da er Verwechslungsgefahr mit der gleichnamigen Formel birgt).


    Daneben/darunter die weiteren Felder, z.B. das gewünschte Telefonnummern-Feld, Typ "Berechnet", "Text" mit der Formel

    Code
    @NameLookup ( [EXHAUSTIVE]; Username; "OfficePhoneNumber")


    Vorteil(e):


    - kein Knopf/Button, der im Lesemodus versteckt werden muß
    - kein F9 nötig
    - Nur 1 Zeile Code pro Ergebnis-Feld
    - keine Fehlerbehandlung nötig
    - mehrere Adressbücher werden automatisch durchsucht (wählbar über das Schlüsselwort EXHAUSTIVE, siehe Designer-Hilfe)
    - keine Abhängigkeit von Vorname , Nachname und solchen Dingen
    - keine Verknüpfung und Abhängigkeit von für User sichtbaren Ansichten
    - kein @SetField mit anschließenden Refreshproblemen der Maske


    Viel Erfolg
    Carsten

    Hallo Carsten,


    wow.... das werde ich jetzt gleich probieren.


    Also Knopf war nie vorgesehen.
    Also es geht über 1 bearbeitbares Feld den Typ habe ich jetzt von "Namen" auf "Dialogfeld" geändert die Auswahloption ist"Adressdialogfeld".


    Habe das gestern noch Anlalog der "Lösung des Chefs gemacht, bekam bei ein paar Feldern dann den Fehler mit dem Index. Habe dann rumgestrickt bis er weg war, aber das ganze sieht nicht besonders toll aus. Erstens steht da jetzt immer erst mein Name drin.
    Dann muss man nachdem man einen anderen Namen gewählt hat wie Du auch angemerkt hast immer F9 drücken.


    Habe es mal probiert
    Habe meinem Feld "TelNr" die Eigenschaft "Text" und berechnet gegeben und Deine Formel eingetragen.
    @NameLookup ( [EXHAUSTIVE]; Username; "OfficePhoneNumber")


    Habe dann die Datenbank geöffnet, bin auf Erstellen neues Dokument, habe bei Username einen Eintrag aus dem Adressbuch gewählt. Leider trägt er in das Feld TelefonNr. nichts ein.
    Kann es sein weil ich im Moment im Insel Betrieb bin und mit den lokalen Repliken der Datenbank und des Adressbuches arbeite?


    Oder habe ich Dussel wieder was falsch verstanden und falsch gemacht?


    Habe gerade nochmal rumprobiert , muss doch die F9 Taste drücken damit er es darstellt.
    Könnte man das noch abstellen?


    Schöne Grüße
    Michaela

    Wenn ich das richtig sehe, hast du einen Part aus der wirklich sher guten Erläuterung von CarstenH vergessen:


    Ich würde zuerst die Namensauswahl nicht über einen Knopf (Button) sondern einfach 1 bearbeitbares Feld vom Typ "Dialogfeld" mit der Auswahloption "Adressdialogfeld" und "Felder bei Schlüsselwortänderung aktualisieren" in die Maske nehmen, wo der Nutzer den Namen auswählen kann. Nennen wir es halt wie in deinem Beispiel USERNAME (auch wenn ich den Namen nicht so toll finde, da er Verwechslungsgefahr mit der gleichnamigen Formel birgt).


    Dann sollte es einwandfrei laufen.

    • Offizieller Beitrag
    Zitat

    Auch wenn ein erfahrener Programmierer gern mal mit Kanonen auf Spatzen schießt...

    Warum haben wir den DBLookup und nicht den NameLookup angesprochen (ich glaube hier kann ich auch im Namen von RockWilder und taurec schreiben).


    Das Ziel war eine neue Ansicht in der names.nsf, über die mit einem einzigen DBLookup dann alle Felder gefüllt werden können, d.h. eine Abfrage anstelle von mehreren Abfragen.
    Da hier von Grund auf gelernt werden soll, ist der DBLookup natürlich universeller einsetzbar als der NameLookup und damit der Code auch eher wiederverwendbar.


    Zum Thema Fehlerbehandlung haben wir mehrfach geschrieben, dass wir Schritt für Schritt uns an die Lösung heranarbeiten und die Fehlerbehandlung zum Schluss einbauen. Außerdem war teilweise durch die Rückmeldungen nicht ersichtlich, woher welche Fehler kommen.


    Klar ist der NameLookup die bessere Variante.


    Gruß
    Dirk

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

    Hallo Zusammen,


    habe das heute in der Arbeit am lebenden System noch mal alles eingetragen. Habe da den Haken sogar gesetzt.
    Super das funktioniert, dann kann ich mich jetzt an den Profildokumenten versuchen.



    Danke für Eure Hilfe und es wäre schön wenn ich mich auch weiter hin melden darf


    Michaela