Datensätze

By Andreas Langmaack (Unlicensed)

Apr 25, 2024

19 min

Add a reaction

Datensätze definieren die "Datenbeschaffung" für schreibende UI-Elemente. Datensätze können den folgenden Metadatenobjekten zugeordnet werden:

Daten-Edit-Element
Multi-Daten-Edit-Element

Eigenschaften der Datensätze

Bereich

Eigenschaft

Wert

| | --- | --- | --- |

Bereich

Eigenschaft

Wert

| | --- | --- | --- | |

Allgemeines

Name

(Name)

Name des Datensatzes

| |

Anhängen an Datensatz der Partner-Kennung

(AppendToPartnerId, AppendToPackageId)

Partner- und Lösungs-Kennung (bei Sage „Sage“) des gleichnamigen Datensatzes, an den diese Definition angehängt werden soll.

Einsatzzwecke:

Makro-Funktionen an Ereignisse des Datensatzes bzw. dessen Felder anhängen
Felder an den Datensatz anhängen
Benutzerdefinierte Felder an den Datensatz anhängen
"Detail Datensätze“ an den Datensatz anhängen

Hinweis: Anhängen ist immer einstufig, Verkettungen sind nicht möglich

| |

Titel

(Title)

Titel des Datensatzes

| |

Nur vorhandene Datensätze editieren?

(EditOnlyExistingData)

Sollen nur vorhandene Datensätze editiert werden? In diesem Fall können keine neuen Datensätze angelegt werden und die entsprechenden Funktionen im UI werden nicht zur Verfügung gestellt.

| |

Verweis auf benutzerdefinierte Felder

(UserDefinedFieldsSources)

Verweisliste auf benutzerdefinierte Felder (Definition in Tabelle „USysSetup“ , Einträge "Tree"="UserFields"; z.B. "Adresse" oder "Artikel"), die dem Anwender beim Editieren zur Verfügung stehen sollen (Achtung: Die hierdurch ermittelten Feldnamen müssen mit dem nachfolgenden „Table1“-Attribut harmonieren; die entsprechende Tabelle muss also die erste sein); jeder Verweis besteht aus „Link“ (Verweis auf „USysSetup“) und „OtherTable“ (muss aktuell leer bleiben)

weitere Verweise auf benutzerdefinierte Felder können bei angehängten Datensätzen (siehe „AppendToPartnerId“ und „AppendToPackageId“) definiert werden

| |

Klassen-Schlüssel für Historie 1

(ClassNameForHistoryTable1)

Hier kann ein Klassen-Schlüssel (z.B. "Adresse") angegeben werden, um beim Speichern des Datensatzes durch einen UI-Aufruf einen Eintrag in die Tabelle "USysClassHistory" zu schreiben (dort Feld "Class"). Diese Tabelle ist die Basis der "Meine letzten..."-Elemente. Bleibt der Eintrag leer, wird kein Eintrag in der Tabelle gemacht.

Client-seitig erfolgt beim Speichern eine automatische Benachrichtigung an alle geöffneten Elemente, die im Attribut "Aktualisierungsbenachrichtigungen" diesen Schlüssel eingetragen haben.

Gilt für SQL-Tabelle 1.

| |

Klassen-Schlüssel für Historie 2

(ClassNameForHistoryTable2)

Hier kann ein Klassen-Schlüssel (z.B. "Kontokorrent") angegeben werden, um beim Speichern des Datensatzes durch einen UI-Aufruf einen Eintrag in die Tabelle "USysClassHistory" zu schreiben (dort Feld "Class"). Diese Tabelle ist die Basis der "Meine letzten..."-Elemente. Bleibt der Eintrag leer, wird kein Eintrag in der Tabelle gemacht.

Client-seitig erfolgt beim Speichern eine automatische Benachrichtigung an alle geöffneten Elemente, die im Attribut "Aktualisierungsbenachrichtigungen" diesen Schlüssel eingetragen haben.

Gilt für SQL-Tabelle 2.

| |

Feldnamen für Historie 1

(ClassKeysForHistoryTable1)

Enthält eine Semikolon-separierte Liste mit Feldnamen der Felder des Datensatzes, aus denen der Schlüssel ("Key") für die Historien-Tabelle "USysClassHistory" gebildet wird, um beim Speichern des Datensatzes durch einen UI-Aufruf einen Eintrag in die Tabelle "USysClassHistory" zu schreiben. Diese Tabelle ist die Basis der "Meine letzten..."-Elemente.

Gilt für SQL-Tabelle 1.

| |

Feldnamen für Historie 2

(ClassKeysForHistoryTable2)

Gilt für SQL-Tabelle 2.

| |

"Hook"-Name (Ab Version 9.0.4)

(HookName)

Definition eines Sage-internen Namens zum Anhängen ("hooken") von hart codierten Erweiterungen.

| |

Kommentar

(Comment)

Beliebiger Kommentar zur Dokumentation.

Der Kommentar wird nicht zum Client übertragen und dient nur zur Dokumentation von Besonderheiten, Hinweisen, etc. Bei Auslieferung/Weitergabe der Lösung wird der Kommentar eingeschlossen, so dass der Empfänger ihn im AppDesigner sieht.

| |

SQL

SQL-Tabelle 1

(Table1)

Datentabelle

| |

SQL-Tabelle 2

(Table2)

Optionaler zweite Datentabelle

| |

globale Datenbank verwenden?

(UseGlobalDatabase)

Soll die globale Datenbank (anstelle der Mandanten-Datenbank) verwendet werden?

| |

Tabelle 1 u. 2 mit Left Join verknüpfen?

(DoLeftJoin)

Die Datensätze in Tabelle 1 und Tabelle 2 werden mit einem LEFT JOIN verknüpft, d.h. in Tabelle 2 werden nur Datensätze geschrieben, die Daten enthalten. Werden die Daten auf der Seite von Tabelle 2 geleert bzw. bei Zahlen auf 0 gesetzt, wird ein ggf. in Tabelle 2 existierender Datensatz gelöscht.

| |

Löschmethode

(RecordDeleteMethod)

Bei zwei Datentabellen ist hier die Löschmethode zu definieren:

0 = In Tabelle 1 zuerst löschen
1 = In Tabelle 2 zuerst löschen
2 = Nur in Tabelle 1 löschen (Löschweitergabe)

| |

Mandantenfeld Tabelle 1

(MandantFieldTable1)

Feldname des Mandaten-Feldes der ersten Tabelle (die Primärfelder und die Mandanten-Felder bilden automatisch die Where-Clause)

| |

Mandantenfeld Tabelle 2

(MandantFieldTable2)

Feldname des Mandaten-Feldes der zweiten Tabelle (die Primärfelder und Mandanten-Felder bilden automatisch die Where-Clause)

| |

Primärschlüsselfeld 1

(PrimaryKeyField1)

Feldname des ersten Primärschlüsselfeldes (die Primärfelder und Mandanten-Felder bilden automatisch die Where-Clause)

| |

Primärschlüsselfeld 2

(PrimaryKeyField2)

Feldname des optionalen zweiten Primärschlüsselfeldes (die Primärfelder und Mandanten-Felder bilden automatisch die Where-Clause)

| |

Primärschlüsselfeld 3

(PrimaryKeyField3)

Feldname des optionalen dritten Primärschlüsselfeldes (die Primärfelder und Mandanten-Felder bilden automatisch die Where-Clause)

| |

Primärschlüsselfeld 4-9

(PrimaryKeyField4-9) (Ab Versoion 9.0)

Feldname des optionalen vierten bis neunten Primärschlüsselfeldes (die Primärfelder und Mandanten-Felder bilden automatisch die Where-Clause)

| |

Primärschlüsseltyp 1

(PrimaryKeyType1)

Primärschlüsselfeld 1 ist

0 = variabel
1 = TAN-basierend auf Tabelle 1
2 = TAN-basierend auf Tabelle 2
3 = fester Wert (Konstante)
4 = fester von Parent übergebener Wert
5 = Automatisch hochgezählt
6 = Fremdschlüssel (nur für Datenklassenfelder erlaubt)

Hinweise für die verschiedenen Einsatzfälle:

Schlüssel des Typs 0 muss der Anwender eingeben
Schlüssel der Typen 1, 2 und 5 werden automatisch neu gebildet
Schlüssel des Typs 4 werden vom Parent übernommen (für 1:N-Beziehungen)
Schlüssel des Typs 5 werden in der zugrunde liegenden Tabelle automatisch gebildet (Identity-Spalten)
Schlüssel des Typs 6 muss der Anwender eingeben, wobei er auf die vorhandenen Werte der jeweiligen Datenklasse eingeschränkt wird

| |

Primärschlüsseltyp 2

(PrimaryKeyType2)

analog "Primärschlüsseltyp 1"

| |

Primärschlüsseltyp 3

(PrimaryKeyType3)

analog "Primärschlüsseltyp 1"

| |

Primärschlüsseltyp 4-9

(PrimaryKeyType4-9) (ab Version 9.0)

analog "Primärschlüsseltyp 1"

| |

Primärschlüsselwert 1

(PrimaryKeyValue1)

Fester Wert für Primärschlüsselfeld 1

| |

Primärschlüsselwert 2

(PrimaryKeyValue2)

analog "Primärschlüsselfeld 1"

| |

Primärschlüsselwert 3

(PrimaryKeyValue3)

analog "Primärschlüsselfeld 1"

| |

Primärschlüsselwert 4-9

(PrimaryKeyValue4-9) (ab Version 9.0)

analog "Primärschlüsselfeld 1"

| |

RowVersion-Feld Tabelle 1

(RowVersionFieldTable1)

Feldname des RowVersion-Feldes der ersten Tabelle

| |

RowVersion-Feld Tabelle 2

(RowVersionFieldTable2)

Feldname des RowVersion-Feldes der zweiten Tabelle

| |

Sortierung

(Order)

Sortieranweisung in Form einer Liste:

angegeben werden jeweils Feldname des Datensatzes (d.h. ein Feld-Verweis; „Name“) und „ASC“ bzw. „DESC“ für aufsteigende bzw. absteigende Sortierung (nachfolgende Felder definieren jeweils Untersortierungen)
im Beispiel „f1;ASC;f2;DESC“ wird zunächst nach Feld „f1“, danach nach Feld „f2“ sortiert
soll ein Feld, das für die Sortierung benötigt wird, ausschließlich hierfür benutzt werden und nicht angezeigt werden, ist es im UI auszublenden
wenn die Eigenschaft leer ist, ist keine Sortierung möglich

Achtung: Da der SQL-Datentyp Text nicht sortiert werden kann, muss der Inhalt eines solchen Feldes bei Bedarf mit „CONVERT(varchar(max), feldname)“ explizit konvertiert werden, was allerdings Performance-relevant ist

| |

Beziehungen

Detail-Datensätze

(DetailDataRecordReferences)

Liste von Verweisen auf abhängige Datensätze (1:n-Beziehung):

Name der Beziehung (wenn der Detail-Datensatz zur Laufzeit in einem Multi-Daten-Edit-Element dargestellt werden soll, muss es sich um den logischen Feldnamen des Multi-Daten-Edit-Elementes im zugehörigen Daten-Edit-Element handeln)
Partner-Kennung
Lösungs-Kennung
Name
Beziehungen (Liste der Key-Felder der beiden Datensätze (jeweils Master-Key - Detail-Key)

| |

Detail-Datenstrukturen(Ab Version 9.0.2)

(DetailDataStructureReferences)

Liste von Verweisen auf abhängige Datenstrukturen (1:n-Beziehung):

Name der Beziehung (wenn die Detail-Datenstruktur zur Laufzeit in einem Multi-Daten-Edit-Element dargestellt werden soll, muss es sich um den logischen Feldnamen des Multi-Daten-Edit-Elementes im zugehörigen Daten-Edit-Element handeln)
Partner-Kennung
Lösungs-Kennung
Name

| |

Löschmethode für Detail-Datensätze

(DoRecordDeleteMethod)

Löschmethode für Detail-Datensätze:

0 = Löschweitergabe über SQL-Trigger
1 = Löschweitergabe auf Basis der Metadaten anhand der Abhängigkeits-Definition (siehe Attribut „DetailDataRecordReferences“)
2 = Code-seitige Löschung (Serverseitiger Code über eine entsprechende DLL-Common-Method; nur für Partner-Lösungen)
3 = Code-seitige Löschung (Server-seitiger Code über eine hart codierte Anpassung im Standard-Code; nur für Sage-Lösungen)

| |

Abfragen für Datensatzkopie

(DataCopyOptions)

Liste der Abfragen, die dem Anwender beim Datensatz kopieren gestellt werden (die Ja-/Nein-Antworten werden zusammen mit den numerischen Schlüsseln an den ausführenden Dienst übergeben. Eine leere Liste bedeutet, dass das Kopieren ohne Anwender-Options-Anfragen ausgeführt wird).

Aufbau:

Index der Option
Abfragetext für die jeweilige Option
Semikolon-separierte Liste der Options-Indizes, die bei Aktivierung auch automatisch aktiviert werden (dient zur Definition von Abhängigkeiten).
Name des betroffenen Datensatzes
Berechtigung verwenden?

Anmerkung: Die Funktionalität zum Kopieren von Datensätzen setzt voraus, dass der Datensatz auf einer Datenklasse basiert, die der Primärschlüssel ist.

Weitere Optionen können bei angehängten Datensätzen (siehe „AppendToPartnerId“ und „AppendToPackageId“) definiert werden

| |

Vorlagenfunktion gesteuert über Feld

(SupportTemplateFlaggedBy)

Durch Angabe eines Feldnamens steht für Neu-Anlagen die Vorlagen-Funktion zur Verfügung. Vorlagen müssen im genannten Feld mit -1 (True) markiert sein. Zur Realisierung wird die gleiche Funktionalität wie für Datensatz kopieren verwendet. Die entsprechenden Felder müssen also korrekt definiert werden.

| |

Ereignisse (Makros)

Vor Änderung

(BeforeUpdate)

Makros, die vor Änderungen eines Datensatzes (d.h. direkt vor dem Speichern) aufgerufen werden

Mit der Funktion "IsRecordInsert" kann im Makro geprüft werden, ob es sich um einen neuen Datensatz handelt
Rückgabe eines Cancel-Flags und einer Cancel-Meldung
Bei Server-seitiger Ausführung:
Ausführung innerhalb der Transaktion

Die Ereignisse werden auf Client- und Server-Seite ausgelöst (sinnvollerweise im Makro die Funktion „IsRunningOnServer“ verwenden, um nur auf dem Server auszuführen und Roundtrips zu vermeiden).

Bei einer hierarchischen Struktur von Datensätzen werden die Ereignisse wie folgt ausgelöst:

Server-seitig: Nach dem Schreiben jedes (Teil-)Datensatzes werden die zugehörigen Makros direkt ausgeführt.
Client-seitig: Vor- bzw. nach der CRUD-Methode wird nur das Makro des obersten (Haupt-)Datensatzes ausgeführt.

| |

Vor Löschung

(BeforeDelete)

Makros, die vor der Löschung eines Datensatzes aufgerufen werden

In in diesem Ereignis aufgerufenen Geschäftsprozessen (siehe Makro-Befehl "AufrufenDll") werden automatisch die zu löschenden Daten zur Verfügung gestellt.
Bei Server-seitiger Ausführung:

Beim Löschen von Teil-Datensätzen (nur in Multi-Data-Edit-Elementen):

Es erfolgt zunächst die Client-seitige Ausführung und beim Speichern des kompletten Datensatzes die Server-seitige Ausführung.
Wenn mehrere Zeilen gelöscht werden, wird dieses Makro für jede Zeile einzeln ausgeführt.

Bei einer hierarchischen Struktur von Datensätzen werden die Ereignisse wie folgt ausgelöst:

Server-seitig: Nach dem Schreiben jedes (Teil-)Datensatzes werden die zugehörigen Makros direkt ausgeführt.
Client-seitig: Vor- bzw. nach der CRUD-Methode wird nur das Makro des obersten (Haupt-)Datensatzes ausgeführt.

| |

Nach Einfügung

(AfterInsert)

Makros, die nach dem Einfügen eines neuen Datensatzes aufgerufen werden Bei Server-seitiger Ausführunmg:

Ausführung innerhalb der Transaktion.

Bei einer hierarchischen Struktur von Datensätzen werden die Ereignisse wie folgt ausgelöst:

Server-seitig: Nach dem Schreiben jedes (Teil-)Datensatzes werden die zugehörigen Makros direkt ausgeführt.
Client-seitig: Vor- bzw. nach der CRUD-Methode wird nur das Makro des obersten (Haupt-)Datensatzes ausgeführt.

| |

Nach Änderung

(AfterUpdate)

Makros, die nach dem Ändern eines Datensatzes aufgerufen werden (Server-seitige Ausführung innerhalb der Transaktion).

Bei einer hierarchischen Struktur von Datensätzen werden die Ereignisse wie folgt ausgelöst:

Server-seitig: Nach dem Schreiben jedes (Teil-)Datensatzes werden die zugehörigen Makros direkt ausgeführt.
Client-seitig: Vor- bzw. nach der CRUD-Methode wird nur das Makro des obersten (Haupt-)Datensatzes ausgeführt.

| |

Nach Löschung

(AfterDelete)

Makros, die nach dem Löschen eines Datensatzes aufgerufen werden (Server-seitige Ausführung innerhalb der Transaktion)

Beim Löschen von Teil-Datensätzen (nur in Multi-Data-Edit-Elementen):

Es erfolgt zunächst die Client-seitige Ausführung und beim Speichern des kompletten Datensatzes die Server-seitige Ausführung.
Wenn mehrere Zeilen gelöscht werden, wird dieses Makro für jede Zeile einzeln ausgeführt.

Bei einer hierarchischen Struktur von Datensätzen werden die Ereignisse wie folgt ausgelöst:

Server-seitig: Nach dem Schreiben jedes (Teil-)Datensatzes werden die zugehörigen Makros direkt ausgeführt.
Client-seitig: Vor- bzw. nach der CRUD-Methode wird nur das Makro des obersten (Haupt-)Datensatzes ausgeführt.

| |

Vor Änderung einer Hierarchie

(BeforeUpdateChildren)

(ab Version 9.0)

Makros, die ausgeführt werden, wenn dieser Datensatz in einer hierarchischen Struktur liegt (1:n-Beziehung). Es wird vor den Update-Ereignissen der Child-Datensätze aufgerufen, aber nur wenn solche Child-Datensätze geschrieben werden.

Die Makros dienen zur Validierung von Abhängigkeiten zwischen den Datensätzen. Bei einem Update werden nur geänderte Datensätze neu geschrieben. Dieses Ereignis kann für eine Gesamtsicht auf alle Child-Datensätze verwendet werden. (Anwendungsbeispiel: Artikelstamm/Stücklistenartikel (Element "recArtikelstammStueckliste.Sage.Wawi").

Funktion „IsRecordInsert“ gibt im Makro an, ob es sich um einen neuen Datensatz handelt.
In in diesem Ereignis aufgerufenen Geschäftsprozessen (siehe Makro-Befehl "AufrufenDll") werden automatisch nur die neuen Daten zur Verfügung gestellt. Die alten Daten müssen bei Bedarf nachgelesen werden.
Rückgabe eines Cancel-Flags und einer Cancel-Meldung
Server-seitige Ausführung innerhalb der Transaktion

| |

Vor Änderung durch API

(BeforeUpdateByApi)

(ab Version 9.0.4)

Makros, die vor Änderung und Neuanlage eines Datensatzes nach dem Setzen der Standard-Werte und vor der Feldvalidierung aufgerufen werden.

Der Zweck des Ereignisses ist es, Werte von Feldern zu setzen, die als Pflichtfelder definiert sind oder Daten-abhängig befüllt werden müssen, im zugehörigen API-Endpunkt jedoch nicht zur Verfügung gestellt werden.

Die Funktion "IsRecordInsert" gibt im Makro an, ob es sich um einen neuen Datensatz handelt.
In in diesem Ereignis aufgerufenen Geschäftsprozessen (siehe Makro-Befehl "AufrufenDll") werden automatisch die neuen und alten Daten zur Verfügung gestellt.
Rückgabe eines Cancel-Flags und einer Cancel-Meldung.

Beispiel: Der API-Endpunkt für Kunden enthält zwar die Felder "Name" und "LieferOrt", zur Speicherung wird allerdings auch das Pflichtfeld "Matchcode" benötigt. Dieses kann im Makro gebildet werden.

Das Ereignis wird nicht auf Client- sondern nur Server-Seite ausgelöst, wenn das Speichern durch einen API-Aufruf initiiert wurde.

| |

Lizenzierung

Lizenz-Kürzel

(LicenseTokens)

Applikationskürzel der zu prüfenden Lizenz (nur in Nicht-Sage-Lösungen verwendbar und änderbar)

| |

Lizenz-Kürzel für Sage

(SageLicenseTokens)

Applikationskürzel der zu prüfenden Lizenz (nur in Sage-Lösungen verwendbar und änderbar)

Eigenschaften der Datensatzfelder

Bereich

Eigenschaft

Wert

| | --- | --- | --- | --- |

Bereich

Eigenschaft

Wert

| | --- | --- | --- | --- | |

Allgemeines

Feldname

(Name)

Eindeutiger Feldname (muss eine korrekte SQL-Feldbezeichnung sein, da der Wert direkt für den Alias-Namen der SQL-Abfrage benutzt wird, für Anwender nicht sichtbar)

| |

Collapse action bar

View all comments

Open Details Panel

Create page

Open Rovo Chat

Add a comment

Add a reaction