Office: Domänenaggregatfunktion als Ersatz für Gruppierung

\@Kyron9000: sorry, daß das jetzt etwas durcheinander ist - wollte nicht ständig neu posten und habe daher mehrfach meine Posts ergänzt

 

..ich auch *Smilie

... ich kapier es nicht oder ihr/du kapierst es nicht. Du möchtest Daten in Tab3 eingeben und iin Tab2 die Daten aktualisieren.
(in Tab2 gibt es diese Tabellen noch nicht... also erst anfügen)

Dann darfst in Formular (Tab2) nur mit ungebundenen Feldern arbeiten und diese Daten mit einem Button in diese Tabellen anfügen.

Falls jemand einen Einspruch gegen diese Vorgangsweise hat... bitte um einen gültigen oder anderen Vorschlag *Smilie.

 

EINSPRUCH !!! *Smilie *wink.gif*

Es geht um DS, die in Tab2 vorhanden sind, in denen aber die beiden Felder für Datum und System-ID leer (NULL) sind.

Und wenn eine Funktionalität, die bei der ursprünglich geplanten 1:1-Arbeit/-Nutzung gang und gäbe ist, diese Felder leert, sollen im Fall gewählter 1:n-Option hinterher Werte aus Tab3 in Tab2 geschrieben werden, falls vorhanden (auch bei 1:n-Nutzung kann es sein, daß es zu einem DS aus Tab2 keine Werte für Datum und System-ID gibt, dann sollen die auch wirklich leer bleiben).

Das soll eine Aktualisierungsabfrage machen, diese beiden Felder von Tab2 aktualisieren.

Und soll halt zu jedem DS ohne Datum/System-ID einen passenden (Beziehung der Tabellen) Datensatz in Tab3 suchen, und wenn mehrfach vorhanden, den mit dem neuesten Datum wählen, und dann sollen die Werte für Datum und System-ID des Tab3-Datensatzes in den Tab2-Datensatz geschrieben werden.

Wie gesagt, wird in Tab2 und Tab3 gar nichts "eingegeben", niemals, nur an Tab1 kommt man schreibend heran. In Tab2 und Tab3 werden ausschließlich durch Aktionsabfragen DS erzeugt, gelöscht und aktualisiert, das sind quasi "Protokoll-Tabellen".
Und auch in Tab1 kann man lediglich editieren, während anfügen und löschen ebenfalls nur Aktionsabfragen können.
Das ist, wie gesagt, nur eine recht kleine, neue Anwendung, die optional zusätzlich zu einer uralten, großen Anwendung genutzt werden kann. Wenn Tab1 nicht über die Haupt-Anwendung, sondern über diese neue Zusatzanwendung editiert wird, muß protokolliert werden, wie das dort geschehen ist.

 

...ich denke ich habe es kapiert... *Smilie
ich werde es anhand deiner smarten DB nachvollziehen und meinen Vorschlag in geraumer Zeit einstellen.
Falls noch niemand einen adäquaten Vorschlag zu Verfügung gestellt hat *Smilie (logisch).

 

...ich denke ich habe es kapiert... *Smilie
ich werde es anhand deiner smarten DB nachvollziehen und meinen Vorschlag in geraumer Zeit einstellen.
Falls noch niemand einen adäquaten Vorschlag zu Verfügung gestellt hat *Smilie (logisch).
PS: die natürlich funktionieren!

 

Hallo,

ein Lösungsvorschlag (SQL):

Code:

 

...ok, ich habe es nachvollzogen... die Tab1 ist ja noch immer in weiter Ferne, also nööö, ich bin draußen.
Wirst sicher eine gute Antwort finden, aber leider nicht von mir, sorry.

 

Hallo,

@readonly:
den Vorschlag hast du aber nicht selber getestet, oder?

wundert mich dann doch, nachdem Eberhard schon bereits in #4 gesagt hat, wie die Ersatzlösung sein müßte.
Anstatt jetzt zwei kaskadierte D-Funktionen zu verwenden, habe ich diese einfach in einer Query zusammengefaßt:
Code:

und dann das eigentliche Update mit:
Code:

Gruß Ulrich

 

...nicht das Muss sondern das Soll eingefügt werden ist das Problem.
Es gibt auch noch eine Tab1... die anscheinend alle vergessen haben.
Die ist aber auch sehr wirksam im einfügen oder nicht einfügen und Beziehung.

Er wird schon die richtige Lösung finden... wird nicht einfach aber geht.

 

\@Alfred:
Tab1 spielt hier überhaupt keine Rolle.

Gruß Ulrich

 

stimmt

da IdTab1 aus Tab1 in seiner 1:1-Beziehung immer identisch ist mit VerwIdTab1 von Tab2, braucht man Tab1 dafür nicht

und habe ich ja auch in meinem Code oben nicht drin gehabt - der super toll aussieht, aber wg. benutzter Gruppierungsfunktion nicht akzeptiert wird

Ich schaue mir die Lösungen oben mal an - danke schonmal!
(dauert aber etwas, bin erstmal nicht am Platz)

 

... auf das Ergebnis bin ich gespannt *Smilie von der DB... falls wir das erfahren.

Aber, eventuell müsste sie irgendwo eingefügt werden... jetzt stellt sich die Frage WO bei einem neuen DS

PS:

Ich verstehe diese Antwort iM absolut nicht.

...Zur Erinnerung, es geht um einen neuen Datensatz in Tab3 der in Tab2 und Tab1 gegeben sein muss.
Wie ist egal er müss überall vorhanden sein, dann kann man erst über einen Übermittlung von SysId reden.
Deshalb noch mal das Formuar von Tab3 muss aber nicht sein... also, für mich nicht mehr.

 

ja, so spektakulär wird das nicht werden
entwickeln gerade an dieser neuen 1:n-Variante, die alte funktionierte ja schon

Sobald das in der jetzt gerade in Entwicklung befindlichen neuen Version tut, was es soll, bleibt das so, und es wird einfach weiter entwickelt, bis diese Version fertig ist.

Falls gemeint war, die ganze Anwendung zu zeigen, das bringt wohl nicht so viel...
Ohne die Haupt-Anwendung kann man mit der kleinen hier gar nix anfangen und das sind so spezielle Dinge, die damit geregelt werden, das ist für "normale Menschen" langweilig und schwer zu überblicken.

 

@knobbi38:

Du hast recht, in meinem Lösungsvorschlag Post #21 dürfte wohl nach der Aktualisierung in der SysId was Falsches stehen.


@micmen:
Wenn du in deinen SQL-Code von Post #13 ein DISTINCTROW einbaust, dann läuft die Aktualisierung. Ob dabei alles korrekt aktualisiert wird, solltest du aber überprüfen.

Code:

Eventuell sollten auch Filterkriterien hinzugefügt werden (... Is Null), damit keine vorhandenen Daten überschrieben werden.

 

...nööö interessiert mich absolut nicht, ich denke ich schreibe in einer Fremdsprache.
Das Formular in dem die Daten für Tab3 eingegeben werden, hat mich interessiert.
Der Schwerpunkt liegt jetzt auf "hat mich interessiert", also nicht mehr.
Alles Gute mit deiner DB