Ersatz für select bei verknüpfter Tabelle
Wenn ein neuer Datensatz angelegt wird, ordnet mein Skript den passenden verknüpften Datensatz zu.
In meiner Tabelle Lagerbestände, mache ich das z.B. so
let me := this;
Produkte := first(select Produkte where SKU = me.SKU)
Geht soetwas auch irgendwie anders, also nicht mit select, sondern direkt in die verknüpfte Tabelle?
Danke
12 Antworten
-
Hallo Arwin, bei einer verknüpften Tabelle lässt man das "select" weg und spricht die Verknüpfung direkt über ihren Namen an (der sich ja vom Tabellen-Namen unterscheiden kann). Bei Filterabfragen entfällt auch das "where", statt dessen werden die Bedingungen in eckige Klammern gesetzt. Also zum Beispiel so:
let me := this; Produkte := first(Produkte[SKU = me.SKU])Wobei 'Produkte' hier wie gesagt nicht für den Namen der Tabelle steht, sondern für den der Verknüpfung.
-
vielen Dank.
Ich glaube, so hatte ich das wohl auch bereits mal versucht, aber Ninox mag das nicht und zeigt mir den folgenden Fehler an:
Jetzt hatte ich gedacht, ok du brauchst das first() nicht, weil es keine multiple values gibt, aber dann kommt etwas, was für mich im Grunde widersprüchlich wirkt
Hat es etwas mit der Art der Verknüpfung zu tun?
Lagerbestände zu Produkte ist hier n:1 -
Hallo Arwin, als "Trigger bei neuem Datensatz" macht das in dieser Form für mich eigentlich keinen Sinn, weil sich "this" ja schon auf den neuen Datensatz bezieht, welcher zum Zeitpunkt der Erstellung aber noch komplett leer ist. Wo soll die SKU also herkommen? Und wenn der neue Datensatz in 'Lagerbestände' aus der verknüpften Tabelle 'Produkte' heraus erstellt wird, dann wird die Verknüpfung von Ninox automatisch gesetzt.
-
hmm.. der neue Datensatz kommt per Api rein.
Produkte ist das Verknüpfungsfeld zur Tabelle Produkte.
Ohne die Aktion Trigger bei neuem Datensatz wird da nix gesetzt oder verknüpft. Mit select funktioniert es wie erwartet, daher nehme ich an
Das Feld SKU in Lagerbestände ist bereits gefüllt, wenn der Trigger ausgeführt wird.
Und da es mit select klappt, hätte ich gedacht es sollte auch mit direktem Zugriff gehen.
Ich bin gerade unterwegs, aber würdest du denn erwarten, dass dein Skriptvorschlag dann im Feld
Lagerbestände.SKU funktionieren sollte, wenn es dort im Trigger nach Änderung ausgeführt wird? Das kann ich ja einfach mal ausprobieren dann…
-
-
said:
hmm.. der neue Datensatz kommt per Api rein.Ein nicht ganz unwesentliches Detail ... Sorry, da bin ich jetzt erst mal raus.
-
Das kann so nicht im Trigger 'Neuer Datensatz' mit einer Verknüpfung funktionieren.
Da hat Axel schon Recht. Bei Neuanlage existiert keine Verknüpfung, da du sie ja erst bei Neuanlage anlegen willst. Erstelle mal ein Funktionsfeld und trage folgendes Script ein: first(Produkte).number(Nr).
Wenn eine Verknüpfung existiert, zeigt er dir die ID aus Produkte. Wenn du die Verknüpfung löschst, ist auch kein Wert mehr im Berechnungsfeld vorhanden. Das ist der Leerzustand des Records bei Neuanlage. Da musst du weiterhin den select benutzen.
Im Gegensatz dazu, hast du mit select einen konkreten Zugriff auf die Records der Tabelle Produkte.
Zur Fehlermeldung im Script:
Du nutzt eine n:1 Beziehung, Da kann man keine Bedingung im Gegensatz zu einer 1:n Beziehung setzen. Mit der Bedingung möchte man ja eine Menge aller Verknüpften Records erstellen und das ist bei einer n:1 Beziehung nur ein einziger Record. Die Fehlermeldung mag unglücklich formuliet sein, aber sie ist dem Beziehungstyp geschuldet. -
vielen Dank, für die ausführliche Erklärung. Meine Fehlannahme war demnach wohl, dass die Tabellen bereits durch die verknüpften Felder irgendwie eine Verbindung haben, also bereits ohne entsprechend gesetzte Datensätze, die dann performanter ist, als eine select Abfrage, welche nach meinem laienhaften Verständnis irgendwie von aussen greift.
-
Hallo Uwe ...
said:
Da musst du weiterhin den select benutzen.Wobei mir immer noch nicht klar ist, wie das mit select gehen soll. Arwin sagt ja auch, dass es bei ihm funktionieren würde:
said:
Das Feld SKU in Lagerbestände ist bereits gefüllt, wenn der Trigger ausgeführt wird.
Und da es mit select klappt, [...]Aber wie kann das Feld 'SKU' bei Ausführung des Triggers bereits ausgefüllt sein? Ich nahm bisher an, dass der Trigger "Bei neuem Datensatz" immer sofort nach dem "create" ausgeführt wird, auch wenn er per API ausgelöst wird.
Ich habe es deshalb in einem anderen Fall so gemacht, dass die per API eingehenden Datensätze erst mal komplett in eine extra Tabelle geschrieben werden und nach Sichtung per Button einzeln oder gesammelt geprüft, in die eigentliche Datentabelle übertragen und verknüpft werden. (Allerdings ging es da auch nur um eine Handvoll Datensätze täglich.)
-
Hallo Axel.
Es macht einen Unterschied aus, ob man den Record über die API anlegt oder per Script innerhalb Ninox. Es sieht so aus, dass die API schneller als der Trigger arbeitet.
Ich habe da ein wenig experimentiert und mir Testdatenbanken gebaut um es nachzustellen (API Erstellung).
Ich sende dir beide in einer persönlichen Nachricht über Discord. -
said:
ich kann jedenfalls versichern, dass [...]Ja, eben, deshalb habe ich ja bei Uwe (API-Profi) nachgefragt, bevor ich deine Aussage großspurig ins Reich der Fabeln verweise. ;)
said:
Es sieht so aus, dass die API schneller als der Trigger arbeitet.Aah, okay. Das erklärt natürlich einiges. Gut zu wissen. Danke für's Ausprobieren!
Content aside
- vor 1 JahrZuletzt aktiv
- 12Antworten
- 90Ansichten
-
3
Folge bereits