Alternative zu Subforms

[Sebastian Süßdorf]

Hallo,

ist es möglich ein Attribut einer Entität in das Layout einer anderen Entität einzufügen und dieses bei einer Neuanlage eines Datensatzes mit Daten zufüllen? Momentan ist mir nur die Variante mit der Subform bekannt.

Vielen Dank für die Hilfe.
Gruß Steffen

[Markus Glitzner]

Hallo,

rein Datenbaktechnisch kann das nur dann (vernünftig) funktionieren, wenn eine 1:1 Beziehung zwischen den beiden Entitäten besteht. Unterformulare haben ja generell eine 1:n Beziehung. Theoretisch könnte man versuchen, das über eine virtuelle Entität zu lösen, allerdings gibt es da wohl Probleme mit dem ODBC Treiber, wenn über eine zusammengesetzte View mehrere Haupttabellen aktualisiert werden sollen und mySQL kann das so weit ich weis überhaupt nicht, darum würde ich hiervon eher abraten.

Die Frage ist, ob es vielleicht nicht einen anderen, eleganteren Ansatz gibt. Kommt halt drauf an, was umgesetzt werden soll.

Gruß
Hugo

[Sebastian Süßdorf]

Hallo!

Wie funktioniert das mit der virtuellen Entität? Ich habe darüber bisher nichts gefunden.

Vielen Dank für die Hilfe.
Gruß Steffen

[Markus Glitzner]

Der Entitätenwizard ermöglicht nun bei der Erfassung einer Entität die Auswahl einer „virtuellen Entität“. Eine virtuelle Entität ist eine Tabelle oder View, die nicht einer anderen (dynamischen) Entität zugeordnet ist. Eine virtuelle Entität muss die typischen System-Attribute mit den entsprechenden Datentypen von Entitäten ohne Statusmodell aufweisen: INTID, INTVERSION, STRCREATED, DATCREATED, STRCHANGED und DATCHANGED. Referenzfelder in virtuellen Entitäten müssen mit dem Prefix „INTID_“ beginnen. Die Verwendung eines Statusmodells kann nicht aktiviert werden. Daten aus virtuelle Entitäten können im Moment nur gelesen werden. Verwendet man eine virtuelle Entität in einem Referenzfeld einer klassischen Entität, so werden keine Fremdschlüssel generiert.

[Jan Giebels]

Leider scheinen virtuelle Entitäten in 3.1.7 aber nicht zu funktionieren. Ohne Support, für den wir hier ja zahlen, aber in diesem Fall nicht erhalten, kann leider auch keine Antwort gegeben werden.

Siehe: https://www.nuclos.de/index.php/de/forum/datenimportexport/4158-daten-aus-2-datenbank-importieren#4730

Dieses Feature wird sehr stiefmütterlich behandelt und scheint nicht sauber implementiert zu sein. Wir werden die Tage mal ein Testupdate auf 3.4 machen, in der Hoffnung das damit die virtuellen Entitäten endlich funktionieren. Andernfalls muss ich hier wohl deutlicher Unterstützung anfordern.

[Stefan Geiling]

Hallo zunächst.

Ich bin mir nicht sicher, ob ich das Thema richtig verstanden habe.
Aber das Vorgehen eine Virtuelle Entität ist folgendes.
Zunächst sollte man über die DB eine entsprechende View erstellen, die man verwenden möchte.
In Postgres schaut dies folgendermaßen aus:
CREATE OR REPLACE VIEW v_test AS
SELECT t.intid, t.strkursname, current_date as datchanged, CAST('system' AS varchar(255)) as strchanged, current_date as datcreated, CAST('system' AS varchar(255)) as strcreated, t.intversion
FROM t_eo_kurs t

Die Rechte sollten entsprechend gesetzt sein (ALTER TABLE v_test OWNER TO postgres;)

Über einen Select kann man dann die Daten überprüfen. (select * from v_test)

In Nuclos kann man dann einfach über den Enitätenwizard sich eine passende Entität erstellen. Hier unter „Erweiterte Einstellungen“ die View bei Virtuelle Entität auswählen. Anschliessend den Enitätenwizard durchlaufen und die gewünschten Einstellungen treffen. Nach dem Abschluss wird dann eine Entitäten-View erstellt, die auf die View verweist. (In meinem Fall T_EO_TEST)

Die Entität kann dann normal als Maske verwendet werden (Nicht änderbar allerdings.) bzw. wenn ReferenzFelder gewählt sind als Unterformular eingebunden werden.

Gleiches gilt auch für den Eintrag unter http://www.nuclos.de/index.php/de/forum/datenim…ank-importieren#4730.
Die Views schauen korrekt aus. Unter der 3.4 kann ich den Fehler nicht nachvollziehen.
Sollte der Fehler dort weiterhin auftreten, müsste man das über ein Ticket im IssueTracking eskalieren.

Ich hoffe, ich konnte helfen.

Viele Grüße,
Stefan

[caf]

Zur Anschauung ein kleines Praxisbeispiel aus einem laufenden Projekt.

Anforderung

In einer Kurs-Management-System einer Sprachschule gibt es zwei Entitäten, in der zeitliche Buchungen separat gepflegt werden: Allgemeine Termine (Meetings, etc.) werden in der Entität Termin gespeichert, Kurstermine in der Entität Kurstermin. Die zeitlichen Buchungen der Lehrer (Entität Trainer) sollen in der Lehrer-Maske in einem Unterformular zusammengefasst visualisiert werden.

Lösung

Die virtuelle Entität Termin-2-Trainer fasst die Termine alle Trainer zusammen. Basis dafür ist die Datenbank-View v_ve_termin2trainer:

CREATE OR REPLACE VIEW v_ve_termin2trainer AS

SELECT
termin.intid, -- ACHTUNG: intid, datcreated, strcreated,
termin.datcreated, -- datchanged, strchanged und intversion
termin.strcreated, -- sind interne Pflichtspalten --
termin.datchanged, -- in diesem Fall werden sie einfach von der
termin.strchanged, -- Quell-Entität übernommen.
termin.intversion, -- Wichtig ist auch, dass die intid in der
-- Sicht eindeutig ist.

trainer.intid AS intid_strtrainer, -- Referenz auf Trainer, zur Anzeige und Verlinkung in UF
termin.intid AS intid_strtermin, -- Referenz auf Termin, zur Anzeige und Verlinkung in UF
NULL::unknown AS intid_strkurs, -- Fake-Referenz auf Kurs, der nicht in Termin referenziert wird
NULL::numeric AS intid_strkunde, -- Fake-Referenz auf Kunde, der nicht in Termin referenziert wird

termin.datdatumvon, -- Dauer des Termins, ablesbar aus den Spalten:
termin.struhrzeitvon, -- datdatumvon, struhrzeitvon, datdatumbis, struhrzeitbis.
termin.datdatumbis, --
termin.struhrzeitbis, --

termin.strnotiz -- Notiz-Feld aus Termin
FROM
t_eo_termin termin
UNION
SELECT
kurstermin.intid, -- Interne Pflichtspalten, s.o.
kurstermin.datcreated, --
kurstermin.strcreated, --
kurstermin.datchanged, --
kurstermin.strchanged, --
kurstermin.intversion, --

trainer.intid AS intid_strtrainer, -- Referenz auf Trainer, zur Anzeige und Verlinkung in UF
NULL::unknown AS intid_strtermin, -- Fake-Referenz auf Termin, da Kurstermin weder eigenes Layout noch ID besitzt
kurs.intid AS intid_strkurs, -- Referenz auf Kurs, zur Anzeige und Verlinkung in UF
NULL::unknown AS intid_strkunde, -- Fake-Referenz auf Kunde, der nicht in Kurstermin referenziert wird

kurstermin.datdatum AS datdatumvon, -- Dauer des Kurstermins, ablesbar aus den Spalten:
kurstermin.struhrzeitvon, -- datdatum, struhrzeitvon, struhrzeitbis.
kurstermin.datdatum AS datdatumbis, --
kurstermin.struhrzeitbis, --

kurstermin.strnotiz -- Notiz-Feld aus Kurstermin
FROM
t_eo_kurstermin kurstermin;

Anmerkungen

• Wichtig für die interne Verarbeitung ist, dass die Systemspalten intid, datcreated, strcreated, datchanged, strchanged und intversion existieren.
• Ebenfalls wichtig ist, dass die intid innerhalb der View eindeutig vergeben ist.
• Referenzen, wie hier auf Trainer, Termin, Kurs und Kunde, müssen über den Entitäten-Wizard noch nachträglich definiert werden; so wie es für gewöhnliche Entitäten üblich ist.
• Sind die Referenzen definiert, werden sie wie üblich in den Unterformularen angezeigt und es lässt sich über das Kontextmenü auch in die verlinkten Masken springen.

[Autor]

Beiträge