Ist das ein Bug?
Ich habe den exakt "selben" Code im Button und im Trigger bei Änderung oben rechts im Feld "geplante Menge".
Wie man im Vid sieht, wird beim Klick auf den Button korrekt ausgeführt, Tabelleneinträge werden gelöscht, anschließend neu eingetragen.
Wenn ich den Update-Trigger auslöse, bleibt die Aktualisierung irgendwie hängen. Was man im Video nicht sieht, ist, dass die Änderung einige Zeit später dann auch im Formular gezeigt wird. Alternativ könnte man aus dem Datensatz raus, und wieder rein, dann ist es auch aktualisiert.
Aber diese Verhalten ist doch wohl ungewöhnlich.
Hier der Code auch
21 Antworten
-
Moin Dusticelli,
die Aktualisierung von Tabellen und Werten nach einer berechneten Änderung funktioniert bei NINOX nicht immer, wie man sich das wünscht. Die Werte werden berechnet, aber nicht immer gleich angezeigt. Was immer hilft, ist der erneute Aufruf des Datensatzes / der Tabelle / der Ansicht, um die Aktuellen Werte einzulesen. Das hast Du ja selbst schon herausgefunden.
Vor vielen Jahren hatte ich dazu mal einen Beitrag geschrieben, um bei der Filterung im Script Funktionen mit where durch eckige Klammern [ ] zu ersetzen.
anstelle: select (Tabelle) where Alter > 5 folgendes nutzen: select (Tabelle) [Alter > 5]Die Abfrage mit "eckigen Klammern" braucht etwas mehr Zeit. Hier der Link zum damaligen Beitrag: https://forum.ninox.de/t/35hr9wq#h7h25v9
Und hier direkt ein paar Details aus dem Beitrag dazu:
Bei where () gehe ich nach meinen Versuchen davon aus, dass beim Aufrufen der Formel die aktuell angezeigten Werte ausgelesen und verarbeitet werden. Ein Verändern der beteiligten Parameter muss dann erst durch einen Trigger angestossen werden. Dabei kann der Trigger ja auch an unabhängiger Stelle mit unanbhängigen Variablen vollzogen werden - auch das schliessen und wieder öffnen des Formulars bringt den gleichen Effekt. Also:
1. eckige Klammern [ ] = direkter Zugriff ("globale Funktion" - reagiert sofort auf alle Änderungen in der Datenbank)
2. where () = temporäre Verarbeitung mit den Werten, die im Moment des Funktionsaufrufs ausgelesen wurden
Vielleicht führt das auch bei Dir zum Erfolg.
Beste Grüße, Kai
-
vielen Dank für den Hinweis, ich habe es mal probiert, aber das ändert in meinem Fall leider nichts am gezeigten Verhalten.
Ich verstehe bei der ganzen Herleitung auch nicht, warum der exakt selbe Code im Trigger bei Änderung ein anderes Verhalten zeigt, wie bei Aufruf in einem Button?
Aber wenn ich sehe, dass dieses Phänomen schon seit Jahren bekannt ist, muss ich mir mal Gedanken mache, wie ich in meinem Fall das Fehlertor abfange. Hatte gehofft, das ist irgendwie ein Bug, der sich beim letzten Update eingeschlichen hat.
-
-
Moin,
es ist zwar exakt der selbe Code, aber die Handhabung und das Verhalten der Trigger ist bei NINOX immer vom jeweiligen Objekt abhängig. Ein Beispiel:
Per Button kannst Du z. B. eine Info mittels alert("Bitte Eingabe überprüfen") auslösen und anzeigen.
Sinnvoll und funktional wäre es, diesen alert bei einem Text- oder Zahlenfeld in der Funktion Trigger nach Änderung zu aktivieren. Leider funktioniert das nicht - alert funktioniert grundsätzlich nicht mit Trigger nach Änderung.
Auch dieses Thema ist schon sehr lange auf der "Wunschliste" vieler User und Experts und wird ebenso lange diskutiert. Ebenso wie die Möglichkeit, Felder zu kopieren, was auch noch nicht realisiert ist.
Es ist also die Devise, sich mit den vorhandenen Mitteln und Hilfsmitteln anders zu behelfen, soweit möglich. In deinem Fall wäre es prima, wenn Du eine Testversion Deiner Datenbank mal hier einstellen könnest - dann kann ich mir das gerne mal ansehen.
-
da hast du natürlich recht, das mit dem unterschiedlichen Verhalten bei Button oder Trigger in Bezug auf alerts() kenne ich auch, aber das ist ja im Grunde wie alerts im Trigger abgeschaltet.
Eine Erklärung wäre demnach, dass der Code im Trigger keine sofortige Aktualisierung einer Formulartabelle auslöst, anders als der Button.
Es ist also die Devise, sich mit den vorhandenen Mitteln und Hilfsmitteln anders zu behelfen, soweit möglichIch werde mich also nach einem Workaround umsehen, mit dem ich eventuelle Fehleingaben abfange. Das ist an der Stelle nicht so tragisch. Meine DB hat schon zu viele sensible Daten, weshalb ich sie nicht posten möchte. Dennoch Danke natürlich.
-
Not this is a cause of the update issue, but check out the post on Ausführungskontext. Buttons are executed locally, unless told otherwise, and triggers are server side. Plus triggers don't always trigger if the field is updated by a script. I think this is to keep from creating cascading scripts that could crash the system.
-
Trigger im Browser werden immer serverseitig ausgeführt sofern keine Zuweisung im Browser erfolgt ist. Serverseitig können keine GUI Aktionen ausgeführt werden. Deshalb funktionieren aler(), dialog(), idAdminMode() dort nicht.
wenn man in einem Button Script do as … anwendet, hat man das gleiche Verhalten wie bei der Triggerausführung.
-
Danke für die Erklärung. Hier nun der neueste Fall in meinem Projekt. Same Place = die Untertabelle in einem Datensatz.
Ich habe ein Formelfeld, das Ergebnisse einer simplen Berechnung als Icons darstellt. Dieses Ergebnis ist auch umgehend da. Wenn ich es aber in der Tabelle sehen will, dauert es ca. 40 Sekunden bis diese dort angezeigt wird.
Da stimmt doch etwas nicht. -
ich frage mal andersherum:
Unter welchen Bedingungen darf man denn erwarten, dass eine Änderung in einem Datensatz in einer Untertabelle bei Rückkehr in die Haupttabelle unmittelbar in deren Tabellenansicht angezeigt wird?
Mir ist bislang diese Art der Trägheit bei der Aktualisierung von Tabellenansichten noch nicht aufgefallen. Kann es nicht sein, dass es bei mir einen anderen Grund gibt?
Z.B. ist die gezeigte Szenerie, eine Untertabelle einer Untertabelle. Kann es sein, dass Ninox das nicht mag?
-
-
So hier auch nochmal dieselbe Situation, aber ich habe nur 2 Fälle im Code, die unterschieden werden sollen. Alles funktioniert wie erwartet
Das kann doch gar nicht mit "serverseitiger" Ausführung zu tun haben. Das eine mal wird die Tabelle sofort aktualisiert, das andere Mal nicht.
-
: Danke für die Erklärung (GUI) und die Möglichkeit des "do as".
: Diese zeitliche Verzögerung habe ich bei alle Ansichten, die neu "durchgerechnet" werden. Es sind hier sicherlich einige Berechnungen, aber es dauert halt einen Moment länger.
-
said:
Das Ergebnis wird in Deinem Feld direkt angezeigt. Du listest die Werte aber in einer Ansicht mit select auf, was einem Filter / einer berechneten Formel entspricht.Good point. Does your Ansicht use a select or a reference link?
-
my Ansicht is a subtable
or to say it precisely: it is a subtable in a subtable
-
-
:
Wie gehst du denn damit um? Wartest du halt?
Das ist eine wichtige und interessante Frage. Ich schicke mal kurz vorweg, dass ich seit 2018 bei NINOX dabei bin, also sehr früh. Zu der Zeit gab es noch „NINOX-Live-Camps“, z. B. in Hamburg. Seit 1998 programmiere ich mit Filemaker Datenbanken für meine Kunden und mich. Die Idee, Filemaker im Laufe der Zeit durch durch NINOX abzulösen, habe ich schnell verworfen. Zum eine sind die beiden Systeme nicht vergleichbar, und zum anderen hat jedes seine Vorzüge. So arbeite ich mit beiden Systemen.
Im Endeffekt investiere ich 50% der Entwicklung in Ninox dafür, um im "2. Durchgang" den Workflow sicher und das Sysstem userfrindly zu machen, Beschleunigungen umzusetzen etc. Ein Beispiel:
Bei Filemaker bedeutet Pflichtfeld, dass der User etwas eingeben MUSS - sonst geht es nicht weiter in der Eingabemaske. Bei Ninox gibt es einen roten Rand um das Feld bei fehlender Eingabe - mehr nicht. Das habe ich so gelöst, dass alle meine Anwendungen oben links einen Button „OKAY“ habe. Dieser Button fragt alle Felder ab und gibt entsprechende Hinweise aus, man kann korrigieren etc.
Nun kann es passieren, dass der Benutzer trotzdem wo anders hinklickt und die Eingabemaske verlässt, OHNE meinen OKAY-Button zu klicken. Dafür sorge ich wie folgt vor: Bei Aufruf der jeweiligen Eingabemaske und somit anlegen des neuen Datensatzes wird zunächst das Auswahlfeld Status automatisch auf „ENTWURF“ gesetzt.
Alle Ansichten liegen auf dem Dashboard, von wo alles aufgerufen / gesteuert wird. Da der Klick außerhalb der Eingabemaske oder der Klick auf meinen OKAY-Button immer eine externe Aktion ist, funktionieren auch alle Berechnungen, alerts und die Ansichten werden umgehend aktualisiert.
Alle Ansichten haben oben als „Titelleiste“ eine Filterauswahl (siehe beigefügtes Bild, Firmennamen sind unkenntlich gemacht) wo sich auch die "ENTWÜRFE" wiederfinden. Die kann man -wenn man möchte- dann später weiterverarbeiten, löschen etc. Es geht nichts verloren.
Diese vielen Filter frage ich in der Ansicht mit einer switch-case ab, unterstützt von der Definition möglichst vieler Variablen am Beginn des Scripts, um mit "festen Werten" zu agieren. Z. B.: let Filter_XYZ := text(Auswahlfeld). Ich sehe also zu, dass ich immer sehr optimierte, möglichst kurze Formeln nutze, unterstützt von globalen Variablen (die werden in deinem Browser gespeichert) und eigenen Funktionen.
Das sind nur wenige Möglichkeiten - und in Kombination gibt es da viele Varianten.
-
:
Was ist denn mit der nativen MacApp? Umgeht die das Problem? Und greift die auf dieselbe Datenbank dann im Netz?
Die native MacApp kann leider nicht alles, was die PrivatCloud kann. Daher nutze ich die App kaum. Was nativ in der App läuft, läuft aber schnell und gut. Wenn ich über die App auf die Datenbank im Netz zugreife, habe ich die gleichen "Warteschleifen".
Oder du musst auf Enterprise switchen und dann bekommst du do as database, das Fußvolk darf ruhig bis zu 40 Sekunden warten. :D
Das kann ich so nicht überprüfen, aber in gleicher Weise ärgert es mich schon, dass mir mein Bauchgefühl sagt, dass mit jedem neuen Update immer mehr Funktionen erst nach der Veröffentlichung durch die User getestet werden (letztes Beispiel mit Rücknahme des ganzen Updates: PDF-Editor).
Und dann habe ich einen gemeinnützigen Kunden, der mit seinem Team ca. 800 Druckaufträge im Monat rausbringen muss. Aber egal, wieviele Mitglieder er in seinem Team haben würde - mehr als 500 dynamische Drucke sind nicht möglich - es sein denn, er wechselt zu dem (für ihn zu teuren) Enterprise .... :D
Das löse ich dann im Endeffekt mit Filemaker, weil dort das drucken und auch versenden von E-Mails (mit Einbindung eigener SMTP-Mail-Server) unbegrenzt nativ enthalten ist, ebenso wie eine pixelgenaues und responsives UX-Design.
-
danke für deine ausführlichen Erklärungen. Das klingt nach viel Gehirnschmalz :)
Kann dein Kunde mit den 800 dynamischen Aufträgen nicht ein Abo bei Carbone abschließen, damit kann man doch mehr als 500 dynamische Drucke erstellen? Eventuell muss man dann über API und nicht direkt über das Druckinterface gehen, aber das sollte funktionieren trotzdem.
Ich glaube Filemaker werfe ich auch mal nen Blick drauf. Was sind die Schwächen von Filemaker? -
: Ja, ich löse das mit Carbone über ein API. Dann haben wir auch ein externes System was bleibt, wenn bei Ninox etwas ändert.
Während Ninox recht einfach vom Aufbau ist, was z. B. die Tabellenverwaltung angeht (einfach eine Untertabelle anlegen), musst Du die teils komplexen Beziehungen der Tabellen und Felder bei FM selber definieren. Die Ninox-Ansichten per select gibt es so nicht, dafür Portale, mit denen Du Daten aus anderen Tabellen ansehen und filtern kannst.
Vielleicht ein Beispiel, auch wenn es natürlich nicht ganz passt, aber die Komplexität gut darstellt: Dir reicht eine kleine Grafikbearbeitung, um die wichtigsten Dinge wie Helligkeit und Kontrast an Bikdern einzustellen, die Bildgröße zu ändern etc. . Das Programm kann noch einiges mehr, ist aber von der Anwendung her so, dass Du mit dem ganzen technischen Teil nicht beschäftigst. Das wäre Ninox: Einfach, flache Lernkurve, schnelle Ergebnisse. Aber Du hast auch manche Grenzen wie Trigger ohne alert oder recht eingeschränkte visuelle Möglichkeiten durch das Web.
Und dann gibt es da noch Photoshop in der TOP-Vollversion. Das ist Filemaker. Es ist komplex, hat eine steile Lernkurve aber dafür enorm viele Möglichkeiten mit einem echten Scripeditor, der nichts mit dem Lowcode von Ninox zu tun hat. Genial: Du kannst nun pixelgenau deine Button und Elemente setzen und ein Userinterface genau für Dich oder Deine Zielgruppe entwickeln (sog. Layouts), und hast Kontrolle über jedes Objekt auf deinem Layout mit zahlreichen Einstellungsmöglichkeiten. Grundsätzlich läuft Filemaker als Standalone auf Mac oder PC. Für mehrere Nutzer brauchst Du eine Serverlizenz mit Hosting, aber das Thema würde hier den Rahmen sprengen.
Der Aufwand bis zum Ergebnis ist bei Filemaker höher - Du musst aber meiner Meinung so gut wie keine Kompromisse eingehen.
Content aside
- vor 13 TagenZuletzt aktiv
- 21Antworten
- 94Ansichten
-
4
Folge bereits