Durch Verknüpfung der Bedingungen mit "and", also bspw.:

V1 := Wert1;

V2 := Wert2;

V3 := Wert3;

select Tabelle where Feld1 = V1 and Feld2 = V2 and Feld3 = V3

Ups, bei V1, V2 und V2 muss natürlich ein "let" davor, sind ja Variablen, sorry:

let V1 := Wert1;

let V2 := Wert2;

let V3 := Wert3;

select Tabelle where Feld1 = V1 and Feld2 = V2 and Feld3 = V3

Also, bei den mehrzeiligen Verknüpfungsfeldern in Formularen kann man die Anzeige der Datensätze ganz einfach filtern, in dem man auf den jeweiligen Spaltentitel klickt und dort eine entsprechende Bedingung vorgibt. Genauso wie in der "großen" Tabellenansicht von Ninox.

Beispiel: In der Tabelle Kunden hast du eine 1:N-Verknüpfung zur Tabelle Rechnungen. Im Kundenformular wird dir also eine Verknüpfungstabelle mit allen Rechnungen dieses Kunden angezeigt. Wenn das sehr viele sind und du nur die ab einem betimmten Zeitpunkt sehen willst, dann klickst du auf den Spaltentitel des Feldes "Rechnungsdatum" (oder wie auch immer es heißen mag) und gibst dort bei "Filter" ein Datum vor, aber dem die Rechnungen angezeigt werden sollen.

Bei den einzeiligen Verknüpfungsfeldern der jeweiligen Gegentabelle macht ein Filtern natürlich keinen Sinn, es ist ja nur ein Datensatz. Dort kann man in den Optionen durch Eingabe einer oder mehrerer Bedingungen bei "Einschränkungen" aber steuern, welche Datensätze zur Auswahl angezeigt werden sollen. Das ist ganz hilfreich, wenn man Verknüpfungen manuell über das Lupensymbol vornimmt und die entsprechende Tabelle sehr viele Datensätze beinhaltet.

Was das "übertragen/sichtbar machen" betrifft: Ja, prinzipiell geht sowohl das eine (z. B. per "duplicate()") wie auch das andere (über eine Ansicht). Um konkreter zu werden, müsste man aber genaueres wissen.

Hallo René, auch diese Frage kann zumindest ich anhand der vorliegenden Informationen nur allgemein beantworten: Es kommt auf das Datenmodell an. Und das wiederum hängt von deinen individuellen Anforderungen ab.

Wir reden offenbar über Angebote, die zu Aufträgen gemacht werden sollen - und diese dann vermutlich auch irgendwann zu Rechnungen. Bei jedem dieser Dokumente hat man in der Regel bestimmte Kopfdaten wie Kunde, Angebots-/Auftrags-/Rechnungsnummer und -datum sowie einzelne Leistungs- bzw- Bestellpositionen verschiedener Anzahl. Zur Abbildung dessen gibt es verschiedene Herangehensweisen:

Eine Tabelle für alle Dokumente, Unterscheidung über "Dokumentart" oder so, und eine Untertabelle für die Positionen (insgesamt 2 Tabellen).
Einzelne Tabellen für Angebote, Aufträge und Rechnungen plus eine Tabelle für alle Positionen (4 Tabellen).

Einzelne Tabellen für Angebote, Aufträge und Rechnungen mit jeweils einer Untertabelle für die Positionen (6 Tabellen).

Keine dieser Lösungen ist per se die beste oder schlechteste, es kommt darauf an. Auf die (zu erwartende) Anzahl der Dokumente, die anfallenden Informationen/Datenfelder und nicht zuletzt natürlich auf die individuellen Abläufe im Unternehmen.

Ninox hat anderen Entwicklungssystemen gegenüber zwar den großen Vorteil, dass man nicht jedes Detail vorausplanen muss, sondern dynamisch vorgehen und immer wieder Anpassungen vornehmen kann, aber es ist natürlich hilfreich, wenn man sich Gedanken über die zu Grunde liegenden Prozesse und Vorgehensweisen sowie die benötigten Datenfelder und -strukturen gemacht hat.

Rein technisch lässt sich fast alles mit Ninox abbilden. Da ich relativ wenige Auftragsdokumente zu verwalten habe, nutze ich für meinen persönlichen Bedarf bspw. die erste Variante mit nur 2 Tabellen (und auch nur einem Drucklayout). Das muss aber keineswegs für andere gelten.

Um dir nun möglichst konkret bei der praktischen Umsetzung deiner Lösung helfen zu können, müsste man wissen, welche der o. g.  Varianten du bevorzugst und wie dein Datenmodell aussieht bzw. aussehen soll. Sonst bleibt man immer im Vagen und muss verschiedene, theoretisch mögliche Varianten durchspielen.

Eine "Ansicht" allerdings, das kann ich ganz allgemein sagen, erscheint mir für einen solchen Anwendungsfall eher ungeeignet. Ich würde grundsätzlich immer dazu tendieren, Angebots-, Auftrags- und ggf. Rechnungsdaten klar voneinander zu trennen und jedes Dokument als eigenständigen Beleg zu betrachten, zumal ein Auftrag ja nicht zwangsläufig immer exakt dem usprünglichen Angebot entsprechen muss (und die Rechnung nicht dem Auftrag).

Wie man aber konkret beim Übertragen von Angebots- in Auftragsdaten samt Positionen mit Ninox am besten vorgeht, hängt wie gesagt vom Datenmodell ab (siehe oben).