Hallo Marco, Datenfelder sind immer Teil einer Tabelle. Aber man kann bei Bedarf ja per "select" aus jeder anderen Tabelle darauf zugreifen. Man könnte also eine Tabelle mit irgendwelchen Basisdaten erstellen, die man an verschiedenen Stellen immer wieder benötigt.

Beispiel: Eine Tabelle namens Wechselkurse mit einem Textfeld für 'Währung' und einem numerischen für 'Kurs'. Ein Datensatz könnte aus "USD" und "0,85" als Umrechnungsfaktor bestehen. Auf diesen Wert könnte man nun von überall aus mit folgender Funktion zugreifen:

first((select Wechselkurse where 'Währung' = "USD").Kurs)

Natürlich könnte man das auch in eine globale Funktion packen und dann jeweils als Variable übergeben. Allerdings glaube ich nicht, dass das in diesem Fall einen praktischen Vorteil hätte. Etwas anderes wäre es bei festen Werten, die sich nie oder sehr selten ändern. Die könnte man in einer globalen Funktion definieren und dann quasi als globale Variable nutzen.

N'Abend zusammen,

mach ich genauso - ich habe in meinen DBs in denen ich es benötige eine (nur für den Admin sichtbare) Tabelle 'Stammdaten', in der ich einen Datensatz mit z.B. Logo, Adresse, Briefkopf-Fuss usw. füttere. In den globalen Funktionen der DB setze ich dann

function Stamm() do
first(select Stammdaten)
end

einen Verweis und kann mit Stamm().FELDNAME auf den Inhalt zugreifen und diesen so zentral pflegen.

lg, Torsten

Hallo Marco,

korrekt. Da ich in der Tabelle Stammdaten eh nur exakt EINEN Datensatz pflege, ist der verwendete Zeiger (last(), first(), ...) letztendlich egal, es wird aus der globalen Funktion immer auf diesen einen verwiesen. Hast Du mehrere musst Du die select-Anweisung in der globalen Funktion natürlich entsprechend anpassen.

lg, Torsten

Auf diese Art globale Variable abzubilden funktioniert wunderbar. Habt Ihr einen Tipp, wie ich diese "globale Variable" auch aus einem beliebigen Formular heraus umstellen kann, ohne in das Formular der "globalen Variable" zu wechseln?

Mein Beispiel:

Ich nutze Ninox zur Dokumentation von Meetings (Tabelle MEETINGS) für mehrere Mandanten.  Da es zahlreiche weitere Tabellen in der Datenbank gibt, verwende ich eine Tabelle EINSTELLUNGEN mit dynamischem Auswahlfeld MANDANT als "globale Variable". Damit lässt sich die gesamte Oberfläche entsprechend des Mandaten umzustellen (Logo, relevante Meeting, ...).

Nun kommt es immer häufiger vor, dass ich "mal eben" in der Meeting-Doku eines anderen Mandanten etwas nachsehen oder sogar ändern möchte. Natürlich geht das durch einen Wechsel in das Formular zu Tabelle EINSTELLUNGEN, ändern des Mandante und anschließendem Rücksprung in Tabelle MEETINGS. Das nervt aber. 

Mir schwebt daher ein Button im Formular zu MEETINGS vor, mit dem ich einen Dialog anstoßen kann, der nach dem Ziel-Mandanten fragt, und der die "globale Variable" entsprechend umstellt.

Wie geht das?

Hi Matthias Behrens ,

wenn ich das recht verstehe, möchtest Du das dynamsiche Auswahlfeld in der Tabelle EINSTELLUNGEN mit einer Eingabe in dem Formular MEETINGS ändern.
Mein Weg dazu wäre folgender:

1. Erstelle in MEETINGS ein identisches dynAWF MANDANT
2. Erstelle eine Verknüpfung zwischen MEETINGS und EINSTELLUNGEN
   (die kannst Du später ausblenden)
3. Verknüpfe von MEETINGS den Datensatz in EINSTELLUNGEN
4. Füge in das dynAWF MANDANT der Tabelle MEETINGS bei
   "Trigger nach Änderung" (zu finden unter "weitere Optionen" im Feld MANDANT)
   dieses Skript ein:

let me := this;
EINSTELLUNGEN.(MANDANT := me.MANDANT)

Wenn Du nun in der Tabelle MEETINGS den MANDANT änderst, wird deine Auswahl im Formular der Tabelle MEETINGS in die Auswahl der Tabelle EINSTELLUNGEN geschrieben.

Damit sollte dann das selbe passieren, wie wenn Du zur Tabelle EINSTELLUNGEN wechselst die Auswahl änderst und wieder zurück wechselst.

Viel Erfolg
Ronald

Moin Ronald,

klasse Ansatz über das dynAWF. Die Umschaltung auf den neuen Mandanten funktioniert. Danke Dir.

Was mich noch stört: Das dynAWF ist ein weiteres Feld der Tabelle MEETINGS und speichert natürlich auch den letzten Wert (Sprungziel zu einem anderen Mandanten). Wenn man später zu einem MEETING-Datensatz zurückkehrt, steht dieses (alte) Sprungziel natürlich noch drin.  Das hat zwei Effekte:

1.) Es irritiert den Nutzer, da das alte Sprungziel im dynAWF nichts mit dem aktuellen Mandanten zu tun hat und 

2.) Der Mechanismus funktioniert nicht, wenn das alte Sprungziel wieder Ziel eines Mandantenwechsels ist. Denn dann erfolgt keine Änderung des dynAWF, und somit zieht der Trigger nicht.

Hast Du auch dafür einen guten Vorschlag.

M

Moin Matthias ,

ich Frage mich gerade, wozu die Auswahl in EINSTELLUNGEN eigentlich gebraucht wird,
bzw. wie deine Datenstruktur aussieht. Es klingt so, als würdest Du in einer Tabelle eine Auswahl treffen, damit in anderen Tabellen etwas passiert. Verstehe ich das so richtig?

Zumindest für deinen beschriebenen Fall würde ich die Auswahl nur bei MEETINGS machen und für dort die entsprechenden Daten aus Tabelle EINSTELLUNGEN? holen oder wo sind die Logos abgelegt? Gibt es denn mehrere Datensätze in EINSTELLUNGEN?
Ein paar Screenshots der einzelnen Tabellen und des Datenmodells könnten mir hier sehr helfen.

Viele Grüße
Ronald
 

Moin Ronald,

EINSTELLUNGEN ist Ersatz für das, was Andere als globale Variable bezeichnen würden. Ein Beispiel ist der aktuell geltende Mandant. Wird ein Mandant ausgewählt, dann werden mir auch nur die Datensätze angezeigt, die eben zu diesem Mandanten gehören. 

Nun ändert sich gerade meine persönliche Arbeitsorganisation: Ich habe 2-3 Kunden gleichzeitig und wechsle den Mandanten während eines Tages mehrmals. Es nervt daher etwas, für das Wechseln des Mandanten aus der Tabelle MEETINGS in die EINSTELLUNGEN zu wechseln, einen Eintrag zu ändern und zurück zu MEETINGS zu wechseln. Ich würde die Umstellung lieber in MEETINGS direkt machen.

Deine Annahme ist also richtig, dass ich in einer Tabelle MEETINGS eine Auswahl treffe, damit in einer anderen Tabelle EINSTELLUNGEN etwas passiert. Das Datenbankmodell habe ich angehängt.

Moin Matthias ,

ich merke, dass ich dafür noch mehr Einblick in die Tabellen brauche, um die Struktur richtig zu verstehen. Um dann beurteilen zu können an welcher Stelle welche Funktion am besten hilft.
Daher mach ich Dir einen Vorschlag.
Kannst Du mich in ein Team einladen, in dem Du eine Kopie von deiner DB importiert hast?
Die Vertraulichkeit / Geheimhaltung der Daten ist für mich selbstverständlich!
Gerne kannst Du auch vertrauliche Informationen durch "Mustermann" ersetzen.
Bzw. ich kann dir auch eine Geheimhaltungserklärung unterschreiben.

Viele Grüße
Ronald