Office: Domänenaggregatfunktion als Ersatz für Gruppierung

Hi,
bisher habe ich immer "gekniffen" und bin auf eine Recordset-Variante ausgewichen, wenn ich bei einer Aktionsabfrage darauf gestoßen bin, daß der Filter für die zu verarbeitenden Datensätze irgendwie eine gruppierte Abfrage benötigt.
Access macht da ja meiner Ansicht nach Blödsinn, wenn es sich weigert, die Abfrage auszuführen, als wollte man die Datenänderungen in einer gruppierten Abfrage ausführen... obwohl die ja nur "ganz harmlos" einen Filter liefert...

Ich habe aber öfter gelesen, man könnte dieses blöde Access-Problem umgehen, indem man in der betr. Abfrage die Gruppierung durch Domänenaggregatfunktionen ersetzt - da kriege ich aber nix funktionierendes hin.

Jetzt habe ich wieder so einen Fall, tabellenmäßig sieht das ganz einfach aus, siehe Beziehungen als Skizze:
Ich habe 3 Tabellen Tab1, Tab2 und Tab3 (wobei man Tab1 für hier sogar vernachlässigen kann).
Tab3 hängt mit einem Verweisfeld 1:n an der ID von Tab2 und Tab2 wiederum mit einem Verweisfeld 1:n an der ID von Tab1.

Tab2 hat lediglich 4 für hier relevante Felder, nämlich ein Autowert-Feld IdTab2, ein Verweisfeld VerwIdTab1 vom Typ Long, das auf das Primärschlüsselfeld von Tab1 verweist, ein Datumsfeld DatAkt und ein Textfeld SysId.

Tab3 sieht genauso aus, IdTab3, VerwIdTab2, DatAkt und SysId (diese Tabelle enthält sogar tatsächlich nur diese 4 Felder).

Die Anforderung ist, daß ich die Felder SysID und DatAkt von Tab2, falls sie leer sind, mit denen von Tab3 aktualisieren muß.
Dabei kann es für jeden Datensatz in Tab2 mehrere Datensätze in Tab3 geben, also für jeden Wert von IdTab2 mehrere Datensätze des Verweisfeldes VerwIdTab2.

Darum muß in Tab3 für jeden betroffenen (beide o.g. Felder sind leer) Datensatz aus Tab2 genau ein Datensatz gewählt werden, und zwar der mit dem höchsten Eintrag im Datumsfeld (und dann muß logischerweise auch die SysId genau dieses Datensatzes genommen werden).

Wäre das möglich mit Domänenaggregatfunktionen?


Ich weiß, es gibt da redundante Daten, das sieht nicht gerade wie der Gipfel der Weisheit aus, aber das ist eine etwas knifflige Sache:
Tabelle 3 kam erst nachträglich als optionale Tabelle dazu und kann von den Usern per Option aktiviert oder deaktiviert werden (manche arbeiten an der Stelle 1:n, manche aber immer 1:1 und benutzen sie niemals). Und wenn deaktiviert, wird wirklich komplett ohne Tab3 gearbeitet, dann enthält die keinerlei Datensätze. Aus dem Grund sind alle Formulare und Funktionen fest auf Tab2 gesetzt geblieben, wo sie schon immer waren.

danke

:)

 

Hallo,

wenn du dich schon damit experimentiert hast, warum zeigst du nicht deine Versuche und warum lädst du nicht gleich deine Testdatenbank mit hoch, oder sollen die Helfer hier das alles erst nachbauen müssen?

Ulrich

 

Hallo,

und wie sollte das funktionieren.
Annahme, du hast eine ID-1 in der Tabelle Tab2 mit SysId 3
In Tab3 gibst jetzt einen neuen Datensatz ein VerwIdTab2 1 aber eine andere SysNr...???
Wo willst diese in Tabelle Tab2 eintragen ohne neuer ID aus Tab2?
Der DS in Tab2 muss als erster geschrieben werden, dass du in Tab3 überhaupt
diese Beziehung nachvollziehen kannst. Und nicht vergessen auf die Tab1 und VerwIdTab1 in Tab2!!
Du kannst nicht in Tab3 einen DS eingeben ohne das du eine Verknüpfung zu Tab2 hast.
Und somit gibt es auch keine neue SysNr in Tab3 ohne das es einen DS in Tab2 gibt.
Dein Vorhaben wollte ich nicht bauen müssen.
Also, ich würde mir, an deiner Stelle, das DB-Modell noch mal gründlich überlegen!
Und bevor ich das einen User zu Verfügung stelle, ausgiebig testen.

PS: es wäre ev. eine Zwischentabelle hilfreich... das war aber nur laut gedacht und nicht bis Ende *grins

 

Bei einem JOIN mit einer Unterabfrage steigt Jet in einer Aktualisierungsabfrage wegen "Doofheit" aus.

Das höchste Datum kriegt man mit einem DMax und könnte dieses direkt im SET-Teil anwenden. Bei der SysId wird es etwas geschraubter, da brauchte man ein DLookup auf das DMax oben drauf, und man braucht einige Präzision mit dem Zusammensetzen.
Drei DAF pro Datensatz sind schon eine ziemliche Orgie. Da dürfte man vorher checken, wie oft und in welchen Dimensionen so etwas ablaufen soll.

Es könnte auch klappen, die Selektion der gewünschten Datensätze in einer gespeicherten Abfrage vorzunehmen und diese mit der Zieltabelle in der Aktualisierungsabfrage zu verknüpfen.
Was dann sicher funktioniert, aber keine Abfrage an sich mehr ist: Inhalt der genannten Selektion in eine temporäre Tabelle ablegen und diese in der Aktualisierungsabfrage verwenden.

 

Ist das "amtlich"? *biggrin.gif* *biggrin.gif*
Genau so erschien mir es all die Jahre, aber ich habe mich nicht getraut, so arrogant zu sein, diese Gedanken als zutreffend zuzulassen... *wink.gif* ...der arme Herr Gates - dieses Problem stammt ja noch aus seinen Zeiten...

ja, solche Gedanken hatte ich tatsächlich, als ich den Beziehungs-Screenshot gemacht habe
Aber ich dachte, das macht mehr Arbeit, sich mit meinem Kram auseinanderzusetzen - ich wollte ja nicht so frech sein, eine Lösung zu erbitten. Ich wollte nur fragen "geht so etwas überhaupt", ggf. mit einer allgemeinen Info, wie man das baut, Gruppierung-Ersatz via Domänenaggregatfunktion.

Ich kann das aber klar machen, ein Muster hochladen!

ist damit das gleiche gemeint wie

Sowas habe ich zu meinen Access-Anfängen ein paar wenige Male gemacht, aber das widerstrebt mir... da mache ich das dann doch lieber DS für DS per Recordset...

Da muß ich jetzt fragen: Speichern als Abfrageobjekt, also eine "Unterabfrage"?


vielen Dank!
und wenn gewünscht, kann ich klar was hochladen



P.S.:
oh, hatte 2 Sachen übersehen, sorry

Das würde bei Usern, die bei sich diese neu zu schaffende Option auf 1:n gestellt haben, sehr oft ablaufen. Betroffen wären immer so roundabout 100 Datensätze, die mehrfach in Tab3 existieren ("mehrfach", aber mit jeweils unterschiedlichem Eintrag bei Datum und System-ID).

*biggrin.gif* *biggrin.gif* Meinst Du vielleicht, ICH wollte das bauen müssen?? *wink.gif*
Das Modell WURDE ausgiebig diskutiert und dieser Weg war nicht meine Idee, ich wollte die beiden Felder der alten Tabelle sterben lassen und für die 2 Felder immer life auf die neue Tabelle schauen lassen. Ich habe mich aber überzeugen lassen, daß diese Variante hier doch viele Vorteile hat - es gibt einfach viele Funktionen der Anwendung, die die beiden Felder in Tab2 beschreiben, und die alle umgebaut werden müßten - ausschließlich wegen der User, die diese neue Option benutzen.
So hat es den Vorteil, daß alle Funktionalitäten bleiben können, wie sie sind, alle Abfragen und Formulare weiterhin passen, und eben nur für die User, die 1:n arbeiten, diese Aktualisierung benötigt wird (das fortwährende Anlegen und Löschen der DS in Tab3 ist ein Klacks).
never touch a running System...

 

...kannst du das Beispiel inkl. Formularen die du verwendest mit Dummy-Daten einstellen?
Ich denke mit einem Hfrm mit RDatensatzherkunft Tab2 und Ufo Tab3 könnte es möglich sein.
Ist eine irre Konstruktion finde ich, kenne ich absolut noch nicht!
Aber, wenn du es bedingungslos so erstellen musst, na dann...
Für mich ist es ja egal, mach jeden ... mit *biggrin.gif*

 

jeden Scheiß...
sprich es nur aus, sprich es nur aus...........

*biggrin.gif* *biggrin.gif* *biggrin.gif*

Formulare sind jetzt keine drin, aber es gibt nur ein Listen- und ein Einzelblattformular, die schauen beide auf eine Abfrage, die Tab1 als Basis hat, mit Tab2 1:1 angehängt (das hat rechtetechnische Gründe, weil in der Basis-Anwendung, an die diese kleine angehängt ist, auf das Pendant zu Tab2 mehr Personen Schreibrecht haben, als auf das Pendant zu Tab1).

Tab1 hängt weit unten in einer Tabellenhierarchie einer alten, sehr großen Anwendung, die ich nicht in diese Beispiel-MDB geschafft habe, und die beiden genannten Formulare zeigen auch die Werte der ganzen darüber hängenden Tabellen mit an.
Aber alle diese Tabellen werden in der aktuellen Anwendung nur lesend benutzt, nur in Tab1 bis Tab3 wird geschrieben, daher sind die anderen Tabellen bei allen Problematiken dieser kleinen Anwendung unrelevant.
Wobei es so ist, daß nur Tab1 von den Usern gepflegt wird, Tab2 und Tab3 werden ausschließlich durch Aktionsabfragen beschrieben, um bestimmte Vorgänge zu protokollieren, also kein User kann deren Felder editieren.

hoffe, das ist ok so...

 

sagen wir mal, nein. Aber... gut soweit, ich sehe es mir an!

PS: aber, ich habe zumindest schon mal Daten in der DB... weniger Arbeit!

 

...OK diese Abfrage habe ich mal erstellt...

Code:

Code:

Das kann's jetzt nicht wirklich sein, oder??
Aber, es sind alle Tab3 SysId Daten in Tab2... kannst aber sicher nicht meinen.

PS: und jetzt gib neue Daten in Tab3 ein ohne das du neue Daten in Tab2 eingibst, auf das bin ich nämlich gespannt.
Das geht nicht ohne das du neue Daten in diese voran gegangenen Tabellen einfügst.
Du wolltest doch etwas in Tab3 eingeben... neue SysId *Smilie kenne mich nicht aus was du willst.

 

nein, also sorry für die Enttäuschung,
aber die leifert 15 Ergebnisse statt 6, das kann schonmal nicht sein...
und ich sehe auch keine Elemente, die jeweils den DS mit dem neuesten Datum suchen

Ich mache es mal so:
Ich versuche, nochmal die Abfrage nachzubauen, die für ihren Filter eine Gruppierung benutzt, und poste das hier - damit klar ist, was das Ergebnis wäre, wenn die Abfrage funzen würde *biggrin.gif*

 

...du musst die Abfrage ausführen (z.B. in deiner BDB) die hast du mir gesendet!!!
Habe nicht mehr *Smilie
PS: wenn du die Abfrage nur ansiehst... siehst du auch nichts. Das ist eine Aktionsabfrage!!!!

Alles gibts, gibt auch einen Gips *Smilie

 

\@Kyron: Ebs hat es doch schon dargestellt. Er will das MAX Datum aus tab3 für den Fremdschlüssel haben, dessen Werte in tab2 für das Datum und die SysID leer ist.
Heißt also DMax bestimmen, das wiederum in Relation setzen, um an die SysID des MaxDatums in Tab3 zu kommen. Die gewonnen Werte in Tab2 für die passende Ids schreiben.
Bekanntermaßen kann Access-SQL sowas nicht.
Gangbare Wege hat ja Ebs schon ausreichend beschreiben.

In deinem Vorschlag berücksichtigst du die Anforderung des Max-Datums nicht.

 

ja klar, hatte ich gemacht

Ich weiß nicht, wie ich das besser formulieren soll, als im Infoformular der MDB geschrieben, ich versuche es mal...

Immer dann, wenn in Tab2 die beiden betroffenen Felder keinen Inhalt haben, sollen sie aktualisiert werden mit Werten aus Tab3. Und zwar soll zu jeder ID (IdTab2 in Tab2 und VerwIdTab2 in Tab3) genau der Datensatz in Tab3 gesucht werden, der den höchsten Wert im Feld DatAkt eingetragen hat, und dann sollen DatAkt und SysId genau dieses Datensatzes in die gleichnamigen Felder von Tab2 geschrieben werden.


P.S.:
Habe jetzt mal das nicht funktionierende Konstrukt ("Operation muß eine aktualisierbare Abfrage verwenden.") nachgebaut.
In meiner Beispiel-MDB müßte das hier als "AAktTab2_sub" gespeichert werden: Code:

und das hier als "AAktTab2": Code:

Die Sache hat allerdings den Haken, daß sie nicht funktionieren würde, falls es mehrere DS in Tab3 gibt, die bei verschiedener ID das gleiche Datum eingetragen haben: Da würde dann ein zufälliger Mischmasch aus SysIds geschrieben...
SOLLTE das aber das einzige Problem sein, gäbe es da für mich einen Workaround:
Da durch Sperrfunktionen der Anwendung sichergestellt ist, daß nie verschiedene SysIds zum gleichen Zeitpunkt in Tab3 geschrieben werden, könnte man das Feld auf Datum+Uhrzeit erweitern, dann wären die Kombinationen aus ID und DatAkt immer eindeutig und so würde auch immer die richtige SysId geschrieben.
Ansonsten dürfte die Abfrage nicht einfach das Maxdatum suchen und dazu "irgendeine" SysId, sondern müßte eben den DS mit Maxdatum suchen und genau zu diesem DS die SysId. Das hatte ich in meinem (eh nicht funktionierenden) Konstrukt gar nicht hinbekommen - auch das hoffte ich, per Domänenaggregatfunktion hinzubekommen.

 

\@fredfred, dann bitte Abfrage zeigen,
schreiben kann ich viel ob das auch so in der Praxis funktioniert ist fraglich.

Nö, verstehe ich absolut nicht. Einfach eine Abfrage zeigen.
Mag schon sein, dass es so eine Abfrage gibt für mich ist aber das ganze eine Fars und keine DB

Im Moment verstehe ich die AccessDB Welt nicht *biggrin.gif*

@micmen, ja ok... mit welchen Daten (oder Datum *biggrin.gif*) die es in Tab2 noch nicht gibt???

Darum habe ich auch um die Formulare gebeten die du verwendest!!!
Das mit dem Datum ist mir fremd, Welches Datum sollte wo verwendet werden.
Bitte einfach zeigen, nicht nur schreiben.

Ist jetzt nicht so, dass ich es nicht hinkriegen könnte, aber mit diesen Angaben schwer.
Also, füge deine Formulare in die BDB ein oder verwende das MaxDatum

 

nein, also eine Farce ist die nicht...
zwar klein, aber schon mit großem Gewinn für die User

Allerdings enthält mein Muster nur die letzten 3 Tabellen einer großen Hierarchie, weil in dieser kleinen Anwendung nur in diesen 3 Tabellen Werte geändert werden können.
Vom User nur in Tab1, aber deren ganze Felder hatte ich hier nicht mit reingenommen.

Habe oben jetzt den Code der Abfragen gepostet, wie sie "funktionieren würden, wenn sie funktionieren täten"... *biggrin.gif*