Office: (Office 2003) Listenfeld: Spalten-Update per VBA Laufzeitfehler 424

Hallo zusammen, mein Access 2003 bringt 'Laufzeitfehler 424 - Objekt erforderlich'. Hintergrund:
Unverbundenes Listenfeld in einem Formular. Die 9 Spalten werden von einer Abfrage geliefert, in der Daten gruppiert / summiert sind. Das Listenfeld soll nur Daten anzeigen und nicht zum Datenupdate dienen. Spalten 6 und 8 liefern eine Stückzahl und ein Gewicht je Einzelzeile. Ich will diese beiden Wertfelder als 'laufende Summe' in jeder Zeile (als Spalte 7 und 9, von der Datenquelle mit 0 geliefert) ausweisen, also jeweils höher werdend.
Während die beiden gelieferten Zellen lt. Debug richtig verarbeitet werden (addieren in prozedur-interne Summenfelder), erzeugt das Einstellen dieser kumulierten Summen in den Spalten 8/9 den Laufzeitfehler.

Ich vermute, der Fehler tritt auf, weil hier Access diese Änderung über die Datenquelle in die Datenbasis zurückliefern können will - was aber nicht erforderlich ist.

Frage: Was ist die Fehlerursache? Liege ich mit meiner Vermutung richtig? Wie kann ich erreichen, dass Access die Datenquelle nur als 'liefernd' ansieht? Könnte ich diese lfd.Summen anderweitig erzeugen?

Als Workaround könnte ich einen Report erzeugen, der ja lfd. Summen bilden kann. Ich hatte das nur noch nicht getan, weil der Formularassistent diesen Report lt. Kombobox nicht als Unterformular auswählen lässt. Wahrscheinlich ist aber das auch möglich, ich habe die Möglichkeit dazu nur nicht gefunden.

:)

 

Hallo!

schau mal hier:
donkarls Access-Seiten

HTH

 

Es ist m.W. bis A2003 tatsächlich nicht möglich, Berichte als Unterformulare zu verwenden.

Da kann ich mir nichts drunter vorstellen.
Hier solltest du vlt. mal beschreiben, was in diesem Zusammenhang passiert.

 

Beim iterativen Abarbeiten der einzelnen Zeilen des Listenfelds (lt. ListCount) über VBA kann ich LESEND auf die einzelnen Spalten zugreifen [Zwifeld = Zwifeld + xxx.Column (5,I)], wenn ich aber einen Spalteninhalt SETZEN will [xxx.Column(6,I) = Zwifeld] tritt der Fehler auf - auch wenn ich (5,I) nochmal ansprechen würde.

 

Hallo,

du kannst die bereits vorhandenen Spalten eines Listen- oder Kombifeldes nicht ändern, zum Aufbau der Datensatzherkunft solcher Steuerelemente stehen lediglich die Methoden Add und Delete zur Verfügung.

Die Lösung wird sein, alle Daten bereits in einer Abfrage zu ermitteln und diese als Datensatzherkunft des Listenfeldes einzusetzen.

 

Dann solltest Du vielleicht ein ListView-Steuerelement benutzen ...

 

Ich bin da ganz bei Anne: Berechnungen in der Datensatzherkunft/Abfrage ermitteln.

Alternative: Das Listenfeld komplett über eine Wertliste füllen.

Ergänzend: Das auch nur dann, wenn als Datenherkunft "Wertliste" gewählt wurde.

 

Da staune ich eh, was da an VBA erfolgt (Laufzeitfehler!) außer ...
Code:

Laufende Summen kann man wie bereits dargestellt direkt in einer Abfrage erzeugen, und der Umgang mit Abfragen sollte einem Datenbänkler nicht so fremd sein.

 

Dass man Listfeld-Inhalte nur über die Datenquelle, aber nicht über VBA bearbeiten/füllen kann, war mir nicht klar. Ich setze VBA nur sehr sparsam einsetze, eben da, wo die Access-GUI keine Lösungen bietet; bin diesbezüglich Autodidakt.
Den Tipp mit den Unterabfragen von Donkarl muss ich mir nochmal genauer anschauen; er sieht zumindest auf den ersten Blick sehr kompliziert aus - und eher so, dass das ein nichtoffizieller 'Trick' ist.
Als Alternative kann ich auch einen Bericht bauen, ich brauche die Infos nicht unbedingt im Formular selbst, wollte aber mit meiner Anfrage hier einen Tick näher an die 'Geheimnisse von VBA' rankommen.
Danke nochmal - bis zum nächsten Mal.

 

Mit einer Abfrage (SQL-Anweisung) kann man deutlich mehr bewirken als nur ein Abrufen von Daten ( SELECT * FROM Tabelle ).

Abfragen sind die erste und eine wichtige Verarbeitungsschicht auf Datenbankdaten (Tabellen), und sie sind sehr leistungsfähig, wenn man sich nur etwas darauf (offensiv) einlässt, vergleiche auch Sql als mengenorientierte Sprache im Gegensatz zum datensatzorientierten Zugriff. Insofern sind Abfragen (SQL-Anweisungen) nur "nichtoffizielle Tricks", wenn man Rolle und Leistungsfähigkeit von SQL unterschätzt oder (fast genau so schlimm) Abfragen falsch oder mit fehlerhaften Design einsetzt.

Der Ausweg VBA (Ereignisabfolge statt Massendatenverarbeitung) ist da oft im Einstieg eher verständlich als SQL, aber nicht wirklich ein Ausweg, da man z.B. verschenkte Performance kaum durch VBA aufholen kann.

Laufende Summen kann man durchaus direkt in Formularen (nicht Listenfeld) oder Berichten erzeugen, aber eben durchaus auch in einer Abfrage, die dann als Datenherkunft für ein Formular, einen Bericht oder ein Recordset verwendet werden kann.

Falls Du Deine Aufgabenstellung etwas genauer beschreibst, könnte man auch einen Vorschlag zu einer solchen Abfrage machen. (Der offensive Umgang mit Abfragen erfordert auch etwas Zeit und Übung - wie woanders auch.)

 

Hallo ebs17, habe erst jetzt gesehen, dass du angeboten hattest, einen Vorschlag zu machen. Hier meine Aufgabenstellung:
Die Anwendung bearbeitet Touren, die an bestimmte Empfänger in einer definierten Fahrtfolge Material ausliefern.
> Hauptformular je Tour.
> Darin Unterformular mit Einzelzeilen je Empfänger, sortiert nach der definierten Folge (muss nicht eindeutig sein). Anzeige als Datenblatt, also je 1 Zeile.
> Inhalt der Zeile: Felder zur Person (aus Datenquelle 1) plus ein gebundenes Listfeld mit Mengendaten (Stck, Gewicht, ..), Bindung an Empfänger.ID
> Datenquelle für dieses Listfeld ist eine AggregAbfrage, die diese Angaben ermittelt (Gruppierung, Summe ...)
> Eingabe für diese Abfrage (also für Person-ID, Stück, Gewicht ...) sind 2 gejointe Abfragen, die selbst aus vorgelagerten Abfragen stammen.
Meine Absicht war, im Listfeld für das Gewicht zusätzlich die lfd. Summe bereitzustellen.
Höhere Access-Versionen können wohl auch bei Formularen (nicht nur bei Berichten) eine lfd. Summe bilden. Diese per Abfrage zu bilden wäre also die Herausforderung. Aktuell brauche ich die Lösung nicht mehr, der spätere Benutzer hat eine andere Lösung gefunden. Trotzdem würde mich (vielleicht auch andere) "die Lösung" interessieren - falls das nicht zuviel Aufwand ist.

 

Laufende Nummer/Summe in Formularen ist auch schon in Acc2000 anwendbar. Als höhere Version würde ich Acc2000 eher nicht bezeichnen.

Ansonsten war aber eine Laufende Nummer/Summe in Abfragen (Anzeige in Listenfeld) in der Diskussion.
Auf das folgende fällt mir aber kein konkreter Vorschlag ein:

 

"Seit Access2000": Jedenfalls gibt es in meinem Access2003 bei Feldern in Formularen keine Eigenschaft mit Namen 'laufende Summe' - wie das bei Berichten der Fall ist. Das mit späteren Versionen hatte ich irgendwo gelesen.

Als Lösungsansatz für eine lfd. Summe in Abfragen würde mir (zu meiner Aufgabenstellung) jetzt einfallen: Die Datenquellen, die die zu summierenden Infos liefern, nochmal in einer neuen Abfrage verwenden, dort die Gruppierung nach Einzel-Empfänger (= Zeile) rausnehmen, als Bedingung '

 

Das es eine solche Eigenschaft gibt hat bisher auch niemand behauptet. *wink.gif*

Hast du dir mal die Links angesehen?

Da niemand deine (Roh-)Daten kennt, ist es schwer zu beurteilen, ob du den richtigen Weg einschlägst.
Vorschlag: probier es einfach mal aus.

Ansonsten: liefer vlt. eine kleine Bsp.-DB mit ein paar Spieldaten und beschreibe/zeige das gewünschte Ergebnis.

 

... doch, es wurde behauptet, schon in Access2000 seien 'Laufende Summen' in Formularen möglich. Siehe Beitrag Nr. 12

Zur von mir skizzierten Lösung: Die würde so funktionieren, weil sie je gelistetem Datensatz alle bis jeweils dahin angefallenen Summen aggregieren würde. Im Sinne meiner Anfrage sehe ich das aber nicht als vernünftige Lösung an. Die in dem DonKarl-Link gezeigte Variante habe ich nicht mehr ausprobiert weil ich, wie gesagt, die Lösung nicht mehr wirklich brauche. Da scheinen aber auch iterative Durchläufe zu entstehen.