Office: Domänenaggregatfunktion als Ersatz für Gruppierung

Ja, was soll ich sagen - FUNZT !! *Smilie
ich verstehe ja so GAAAR nicht, wie knobbi38 zu dem Rang "MOF Koryphäe" kommt? *biggrin.gif* *biggrin.gif* *biggrin.gif*

nee, super, ich werde das mal untersuchen...
Die Sub-Abfrage enthält eine Gruppierung, die aber in der Baukasten-Entwurfsansicht gar nicht zu sehen ist.
Und ich schaue, ob die tatsächlich den Datensatz wählt, oder passend zum Max-Datum "irgendeine" SysId, falls es da mehrere gibt.


1000 Dank!

Damit das nicht falsch verstanden wird:
MIR reicht das an dieser Stelle zu 100%, aber ich denke, andere mit dem gleichen Problem werden nach Studieren von Fragestellung und Deinen beiden Code-Schnipseln auch nicht schlauer sein, als zuvor...?
Ich finde ja immer Super, wenn Foren-Threads gleich auch als Nachschlagewerk dienen, so daß folgende Ratsuchende gar nix mehr posten müssen, sondern ihre Antwort direkt finden. Daher versuche ich auch die Titel so "Ratsuchender-kompatibel" zu machen, wie möglich, faölls ich selbst der TO bin.

Also wenn Du Lust hast, könntest Du Deine Lösung evtl. noch kommentieren - aber wie gesagt: nicht für mich.

danke!

 

sorry, ich hatte in dem Post-Sturm mehrere übersehen... *rolleyes.gif*

Das ist so richtig, aber für Tab2 und Tab3 gab es noch nie ein Formular und für Tab3 wird es evtl. nie eins geben.
Für Tab2 sowieso nicht, weil die 1:1 an Tab1 hängt, nur für die gibt es die genannten 2 Formulare Liste und Einzelansicht.

Und es ist immer sichergestellt, daß es für Tab3 immer die zugehörigen DS in Tab2 gibt, und für Tab2 die in Tab1.
Das also braucht diese Aktionsabfrage nicht zu prüfen und nie wird es erforderlich, daß zuerst wo was angefügt werden muß.

s.o. zum Formular
und das habe ich ständig im "schriftlichen Teil meines Lebens", daß ich denke, ich schreibe in einer anderen Sprache... mein Gedanke ist ständig "war mein Chinesisch jetzt wirklich SOOOO schlecht??" *Smilie

ach Mensch... JETZT kapiere ich das Problem, von dem Du immer meintest, das müsse berücksichtigt werden!!! Ja, nachvollziehbar, aber da gibt es kein Problem:
Wie gesagt, gibt es in der 1:1-Verwendung gar keine DS in Tab3, Tab3 wird nur auf Userwunsch "zugeschaltet". Und die Aktionsabfragen kümmern sich auch bei aktivierter 1:n-Option immer zuerst um Tab2, das war ja der Hintergedanke: Durch diese (wenigen...) redundanten Daten konnten sämtliche Funktionalitäten beibehalten werden, es gab keine Änderungen. Sondern auch aus Entwicklersicht ist Tab3 nachträglich drangehängt, quasi als letztes wird auch die noch gefüllt oder geleert (Aktualisierungen gibt es dort gar nicht, meine ich jetzt so aus dem Stehgreif).
Also bis Tab3 ihre Datensätze hat, sind die in Tab2 schon "längst vorhanden"...
Tab3 wird vom Code immer als letztes zusätzlich noch behandelt, mit zusätzlichen Aktionsabfragen.

diesen 2. Code hatte ich ganz verpaßt... *depressed
Klar, die Prüfung auf IST NULL ist wichtig, muß für eins der beiden zu aktualisierenden Felder gemacht werden.
Diese Lösung schaue ich mir auch nochmal an!

 

...nur noch ein kurzes Statement von mir... (kenne mich ja nicht so aus *Smilie)
Was ist nun, wenn in die Tab3 eine neue SysID eingegeben wird mit
allen relevanten Daten, wird diese SysID auch in die Tab2 übermittelt oder nicht.
Oder ist das wie "Wurscht"... das war für mich leider relelvant.
Anscheinend ist das nicht so, das war anscheinend mein Denkfehler
bei der Lösung deiner Fragestellung.
Das wird anscheinend erst bei einer Zusammenfassung wieder vereint.
Arge DB für mich undenkbar aber jedem das seine *Smilie

 

neeee, weniger Denkfehler, vermute ich - eher "unser" Problem, daß ich Dich wieder abgehängt habe durch eine nachträgliche Ergänzung in einem Post von mir, die Du nicht mehr bemerkt hast...
In Post 32 bin ich auf dieses Thema nochmal eingegangen

Wie gesagt, wird in Tab3 nie was "eingegeben", nur Aktionsabfragen schreiben in der. Und immer wird zuerst in Tab2 geschrieben, erst in einem zusätzlichen Schritt auch in Tab3 (falls der User das in seinen Optionen überhaupt aktiv hat, daß es für jeden DS aus Tab1/Tab2 n System-IDs - und somit irgendwelche DS in Tab3 - geben soll).
Tab2 ist eben immer das Master für diesen beiden Felder.
Und wenn eine Abfrage in Tab2 Inhalte löscht, die "normalerweise" (1:1-Nutzung) dann auch leer bleiben würden, und in Tab3 quasi "Reservedatensätze" gefunden werden, dann werden deren Informationen in Tab2 übernommen - aber die DS in Tab2 sind immer bereits vorhanden.

 

\@knobbi38:
funktioniert 100% sauber

@readonly:
der Filter hatte gefehlt, aber der ließ sich auch im Entwurf nachträglich noch zufügen - "mischt" allerdings verschiedene SysIds zusammen

An der Lösung von readonly hat mich fasziniert, daß sie ohne Unterabfrage auskommt! *yelrotflmao Und daß sie irgendwie eine "virtuelle Unterabfrage" mit generiert - wie raffiniert... Bis mir die Namens-Syntax dieser "virtuellen" Unterabfrage so seltsam bekannt vorkam... Und ich gerafft habe, daß diese Lösung meine eigene Unterabfrage verwendet, obwohl die zum Upload-Zeitpunkt noch gar nicht existiert hatte!! Ich hatte in meinem Post des SQL-Codes der nachträglich gebauten Abfragen auch die Namen mit erwähnt, unter denen sie zu speichern wären... Magic readonly entzaubert...
Mann, Ihr schafft mich!

Die Lösung von knobbi38 scheint nichts zu mischen, als ob sie intern nach SysId sortieren würde - wovon ich aber nichts sehe... Überhaupt verstehe ich die Funktionsweise dieser Lösung nicht - so ein Abfragen-Duo könnte ich niemals alleine bauen, fürchte ich.


Ich muß mal etwas SQL-Unterricht nehmen, denke ich - ebs17 hat da was in seiner Signatur...

nochmal danke *Smilie

 

Hallo,

nochmal zur Erläuterung: die Query "qryGetUpdateDataByID2" besteht im wesentlichen aus zwei Teilen:

Code:

Code:

Damit erhält man eine Query, die für das geplante Update verwendet werden kann:
Code:

Damit das Update funktioniert und nicht von Jet zurückgewiesen wird, ist hierbei der Umweg mit DLookup notwendig, womit die jeweiligen neuen Werte aus dem Ergebnis von "qryGetUpdateDataByID2" ausgelesen werden.
(siehe auch #4)

Gruß Ulrich

PS: Die Idee stammt im wesentlichen von Eberhard, insofern gebührt im die Ehre. Ich habe die Idee im wesentlichen nur umgesetzt.

 

\@micmen:
Ich hatte ja extra geschrieben: Wenn du in deinen SQL-Code von Post #13 ein DISTINCTROW einbaust, dann läuft die Aktualisierung.
Es kommt also keine Fehlermeldung mehr. Ob dein eigener SQL-Code richtige Werte aktualisiert, hatte ich nicht überprüft, schien mir aber nach deinen früheren Angaben so zu passen.

Nebenbei, die Lösung mit der Unterabfrage qryGetUpdateDataByID2 von knobbie38 ist nur zur Aktualisierung der SysID nötig. Für die Aktualisierung von DatAkt würde die einfache Abfrage (1. Schritt laut Knobbi38) genügen, oder mein früherer Vorschlag mit DatAkt = DMax("DatAkt","Tab3","VerwIdTab2 = " & IdTab2)

Bei großen Datenmengen könnte das performancemäßig was ausmachen.

Ev. sollte neben der SysID auch DatAkt in Tab2 und Tab3 indiziert werden.

 

danke wieder,
ich werde mir das nach Feierabend in Ruhe zu Gemüte führen - mit viel Hirn

Dafür, daß es zur Zeit eigentlich nur Notbetreuung gibt, ich aber über kein Mama/Papa in systemrelevantem Beruf verfüge, ist die Betreuung hier ja exzellent !!!
*Smilie

 

Wow, zu einer einzelnen Aktualisierungsabfrage gibt es allerhand zu schreiben.

Die oben gezeigte Variante mit zwei JOIN's in einer Aktualisierungsabfrage habe ich bisher noch nicht gesehen und erst recht nicht verwendet. Das muss ich mir näher ansehen.
Die wirkliche Verwendung von DISTINCTROW ist mir immer ein Rätsel geblieben. Außer der obigen Verwendung fand ich erst einen sinnvollen Einsatz (Löschabfrage mit gejointen Tabellen). Hat da jemand weitergehende Informationen oder Lesestoff dazu?

Um meine obigen Informationen zu vervollständigen:

1) DAF-Orgie
Code:

Wer so etwas mit dem ersten Versuch fehlerfrei durchschreibt, beherrscht sein Handwerkszeug.

2) Einsatz einer temporären Tabelle, unter Einbeziehung Grundlagen - SQL ist leicht (13) - Temporäre Tabellen
Code:

Das sieht jetzt nach etwas viel aus, aber wenn man sein temporäres lokales Backend erst einmal eingerichtet hat, kann man es auch fortlaufend nutzen.
Das Zusammensetzen des Ablaufes ist relativ übersichtlich und erfordert weniger Abstraktion als das Zusammensetzen einer Abfrage wie in 1).
Von der Laufzeit her dürfte es dann nicht zu schlagen sein.

 

Überraschende Wendung (für mich): Mit der zusätzlichen Verwendung von DISTINCTROW wird die Doofheit von Jet überwunden und die Abfrage in eigentlich gedachter Formulierung ausführbar:
Code:

Jetzt müsste nur noch jemand erklären können, warum das so ist und was DISTINCTROW ganz genau macht.

 

UPDATE DISTINCTROW ist wohl ein alter Hut.
Das hilft nach meiner Erfahrung aber nur in wenigen Fällen.
Früher - als ich noch mehr mit Access als Backend gearbeitet habe - war das immer der erste Versuch. Dann kam erst die Alternative über UDF oder DomFunc.

Wenn man sich das Leben leicht machen will, verzichtet man eben auf Access als DB. *wink.gif* Aber das weißt du ja eh.

Interessant wäre es aber dennoch, ob man eine Regel ableiten kann, wann DISTINCTROW hilft.