2 Abfragen einer Tabelle in Endlosformular bearbeiten

Moderator: ModerationP

2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon inco12345 » 17. Okt 2019, 06:53

Servus Zusammen,

alle paar Monate stoße ich in irgendeiner Form auf dieses Problem.
Eine Tabelle wird mit zwei oder mehreren Abfragen gefiltertet werden.

Nun sollen diese Abfragen zusammengefasst und in ein fortlaufendes Formular gepackt werden.
Es soll eine Gruppierung vorgenommen werden, welche eine Überarbeitung der Werte zulässt.

vereinfachtes Beispiel:

Code: Alles auswählen
  ID G1 W1
  1  1   12
  2  1  13
  3  2   11
  4  2  14


Abfrage 1
Code: Alles auswählen
  ID G1  W1
  1  1   12
  3  2   11


Abfrage 2
Code: Alles auswählen
  ID G1 W1
  2  1  13
  4  2  14


Ziel Abfrage:
Code: Alles auswählen
G1 T1.W1  T2.W2
1   12   13
2   11   14


Darstellung im fortlaufenden Formular (so wie in einem Bericht)
Code: Alles auswählen
G     W
1     12   
      13
2     11   
      14


Das ist zwar mit einigen Abfragen möglich, nur ist es anschließend stets unmöglich die Werte zu überabeiten.
Hab mittlerweile schon einige Dinge probiert:
- zwei Unterformulare in das fortlaufende Formular packen
- UNION Abfrage
- Kombinierte Select Abfrage
- Bericht erstellen und mit Klick-Events (müsste gehen ist aber aufwendig)
... (schon wieder einiges vergessen)

Muss mal experimentieren, wie und ob ungebundene Felder mit zwei Recordsets eine Möglichkeit darstellen.
Kennt einer von den Experten hier ein Workaround das mir helfen könnte?

Viele Grüße
Andreas
inco12345
 

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon mmarkus » 17. Okt 2019, 07:11

inco12345 hat geschrieben:Das ist zwar mit einigen Abfragen möglich, nur ist es anschließend stets unmöglich die Werte zu überabeiten.


Das sollte doch jedem klar sein, dass die Bearbeitung nicht möglich ist.
Access weiß ja nicht um welchen Eintrag es sich jeweils in der Tabelle handelt.

Ein einfacher Weg:
Du bearbeitest die Werte in einem ungebundenen Detailformular.
Dann kannst du selbst für das Aktualisieren der Daten in der DB und dem EndlosForm sorgen.

Etwas schwerer, dafür ohne Detailform (muss man aber testen ob das klappt):
Du verwendest ein ungebundenes ADO Recordset als Basis für das Formular.
Im BeforeUpdate Event schreibst du die Änderungen in die Datenbank.
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1646
Registriert: 16. Apr 2012, 16:07
Wohnort: Oberösterreich

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon inco12345 » 17. Okt 2019, 07:35

Das sollte doch jedem klar sein, dass die Bearbeitung nicht möglich ist.

Naja, mir war es halt ne Weile nicht klar.
Aber du hast Recht, es ist eigentlich logisch.

Du bearbeitest die Werte in einem ungebundenen Detailformular.
Dann kannst du selbst für das Aktualisieren der Daten in der DB und dem EndlosForm sorgen.

Etwas schwerer, dafür ohne Detailform (muss man aber testen ob das klappt):
Du verwendest ein ungebundenes ADO Recordset als Basis für das Formular.
Im BeforeUpdate Event schreibst du die Änderungen in die Datenbank.


Vielen Dank. Kannte diese Möglichkeiten bisher nicht.
Werde beide Varianten probieren.
inco12345
 

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon Bitsqueezer » 17. Okt 2019, 08:31

Hallo,

disconnected ADO Recordsets ist eine Möglichkeit, allerdings nicht ganz einfach umzusetzen, da Access in einigen Punkten etwas zickig ist.

Eine andere Alternative besteht darin, daß Du eine Tabelle baust, die aus G, W1 und W2 besteht, diese füllst Du vor Aufruf des Formulares mit den gewünschten Werten und entweder beim Speichern jedes Datensatzes oder beim Verlassen des Formulares für alle Datensätze als ganzes kannst Du die Werte der Hilfstabelle dann wieder in die echten Tabellen zurückschreiben.

Hier gilt es natürlich zu beachten, ob die Datenbank multiuserfähig sein soll. Wenn ja, muß die Hilfstabelle eine zusätzliche Spalte mit der UserID beinhalten, dann kannst Du die Werte für den aktuellen User schreiben und vor Aufruf des Formulares die ggf. früheren Werte dieses Users aus der Tabelle entfernen und wieder mit den aktuellen Werten füllen.

Beim Zurückschreiben in die echten Tabellen muß man dann natürlich eine Synchronisation ausführen, wie es auch bei disconnected Recordsets notwendig wäre.

Vorteil: Es ist eine ganz normale Tabelle, die Du ganz normal an ein Formular binden kannst, Access macht keine Probleme und die Programmierung der eigentlichen Eingabe ist einfach.
Außerdem besteht natürlich die Möglichkeit, entweder je Datensatz oder für die ganze Hilfstabelle ein komplettes Undo zu machen, auch für Löschungen, was mit normal angebundenen echten Tabellen natürlich nicht geht. Denn wenn ein Datensatz aus der Hilfstabelle futsch ist, kann man ihn einfach wieder aus den echten Daten neu laden.

Nachteil: Die Synchronisation muß natürlich selbst programmiert werden. Das bedeutet: Neue Datensätze können eingefügt werden, aber bei Änderung und Löschung muß vorher erst der aktuelle Stand der Datensätze in den echten Tabellen geprüft und verglichen werden und bei Konflikten entweder automatisiert entscheiden (z.B. Strategie: der letzte, der eine Änderung in die Hilfstabelle für den gleichen Datensatz geschrieben hat, gewinnt) oder der User muß entscheiden, ob seine Änderung oder die des anderen Users verwendet werden soll.

Bei disconnected ADO Recordsets kann man entweder ein Recordset mit XML definieren oder durch Definition jedes Feldes im Code oder man verwendet eine fertige Tabelle (wie die o.g. Hilfstabelle) und trennt danach die Verbindung, dann wird die Felddefinition aus der Tabelle entnommen.
Access ist auf die Verwendung dieser Art von Recordsets nicht richtig vorbereitet, so daß es zu Konflikten kommen kann, etwa bei F5 für Aktualisierung. Die ID-Vergabe bei Auto-IDs regelt an sich ADO, aber das funktioniert dann nicht immer ganz sauber mit einem Access-Formular.
ADO hat für die Synchronisation eigene Methoden, die die o.g. Vergleiche zwischen Offline- und echten Tabellen regeln, allerdings muß trotzdem im Fall eines Konfliktes eine Entscheidung für die Vorgehensweise programmiert werden, man spart also nicht sehr viel gegenüber der o.g. Methode.
Es kann auch passieren, daß Access komplett crasht (alles schon mal getestet, zuletzt mit A2010).

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 7219
Registriert: 21. Jun 2007, 12:17

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon incoggnito » 17. Okt 2019, 08:56

Vielen Dank für eure Unterstützung!

Ich habe mal versucht eine kleine Beispiel Datenbank (Acc2013) für den zweiten Vorschlag von Markus (ungebundener ADO Recordset) zu erstellen.
Hier kann ich allerdings aktuell nicht speichern. Vermutlich irgendein dummer Bug, geht das in die von dir ersinnte Richtung?

@Christian,
es ist eine Mehrbenutzer Datenbank, allerdings ist das in diesem Fall sogar unkritisch.
Die Ursprungstabelle wird aktuell schon durch eine Funktion (temporär und lokal im Frontend) erstellt.
Ich müsste eigentlich nur die Berechnung weiter fortführen.
Dann könnte ich die Tabelle einfach binden.
Manchmal sieht man den Wald vor lauter Bäumen nicht :mrgreen:
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
incoggnito
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3
Registriert: 17. Okt 2019, 08:42

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon mmarkus » 17. Okt 2019, 09:31

Es funktioniert mit ADO problemlos.

In der Form_BeforeUpdate hast du allerdings ordentlich geschlampt.
Die Fehlermeldungen hätten dich da ja hinführen müssen.


Code: Alles auswählen
Private Sub Form_BeforeUpdate(Cancel As Integer)
 
Dim rsTab As New ADODB.Recordset

With rsTab
    .CursorLocation = adUseClient
    .Open "SELECT * FROM tblSides;", conn, adOpenStatic, adLockOptimistic
   
    .Filter = "ID =" & Me!txtID1
    .Fields("Wert") = Me!txtW1
   
    .Filter = "ID = " & Me!txtID2
    .Fields("Wert") = Me!txtW2
    .Update
    .Close
End With

Set rsTab = Nothing

End Sub



LG M
ms access what else
mmarkus
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 1646
Registriert: 16. Apr 2012, 16:07
Wohnort: Oberösterreich

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon incoggnito » 17. Okt 2019, 10:17

In der Form_BeforeUpdate hast du allerdings ordentlich geschlampt.
Die Fehlermeldungen hätten dich da ja hinführen müssen.


Bei mir funktionieren die Fehlermeldungen manchmal nicht.
Ich sehe nur dass was nicht geht. Sobald es ein anderer Nutzer ausführt, geht es bei mir auch wieder.
Danke für den BugFix.

Viele Grüße
Andreas
incoggnito
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3
Registriert: 17. Okt 2019, 08:42

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon Bitsqueezer » 17. Okt 2019, 11:21

Hallo

mal abgesehen von dem Bug, es zeigt bereits dieses kleine Beispiel, daß es so nicht geht.

  • schon mal F5 gedrückt? Hatte ich oben erwähnt.
  • schon mal versucht, Datensatz 7 bei geöffnetem Formular direkt aus der Tabelle zu löschen und dann einen Wert für Gruppe 4 einzugeben? Soviel zum Thema Multiuser.
  • schon versucht, einen neuen Datensatz anzulegen?
  • schon versucht, in der wie oben geöffneten Tabelle einen Wert zu verändern und dann für die gleiche Gruppe im geöffneten Formular? Ups...Multiuser wieder gecrasht.

Das ist es, was ich mit Synchronisation und Konfliktbehandlung meinte. Es müssen alle Fälle sorgfältig programmiert werden.

Übrigens deklariert man eine Objekt-Variable in VBA nicht mit dem Schlüsselwort "New", das ist nur bei "richtigen" objektorientierten Programmiersprachen i.O. In VBA bewirkt das, daß man eine Variable dann nicht mehr mit Set...=Nothing zurücksetzen kann. In VBA gilt: Deklarieren, dann per Set mit New initialisieren (falls erforderlich).

"SELECT *" müßte sich eigentlich mal rumgesprochen haben, daß man das nicht verwenden sollte. Für die Demo ist das OK...

"adBigInt" ist eine 64Bit-Zahl, mit der Access oft nicht zurechtkommt (je nach Version). Eine normale ID ist "adInteger", was 32Bit entspricht, was Access "Long Integer" entspricht (oder VBA Long).

Warum den CursorType in Init erst auf adOpenKeyset und dann adOpenDynamic im Open-Befehl? Eins von beiden kann man sich klemmen.
"adOpenStatic" sollte hier genügen, denn es ist ja ein Disconnected Recordset. "adOpenKeyset" erstellt einen künstlichen Index, um eine Zeile eindeutig zu identifizieren (im Recordset) und adOpenDynamic erkennt Änderungen durch andere Benutzer, was bei einem Disconnected Recordset natürlich auch nicht geht.

In der vorgestellten Form hat ein Disconnected Recordset keinerlei Vorteile, weil man auch die BatchUpdate-Methode zur Synchronisation nicht verwenden kann, da die Werte auf verschiedene Zeilen der zugrundeliegenden Tabelle aufgeteilt werden müssen. Dafür hat man die zusätzlichen Nachteile, wie man an z.B. der F5-Geschichte sehen kann.

Auch wenn es eine lokale Tabelle ist und damit eigentlich kein Multiuserzugriff stattfindet, bleibt immer noch, daß man so keinen neuen Datensatz anlegen kann, daß F5 nicht funktioniert.
Übrigens müssen für jede Gruppe mit dem bestehenden Code immer genau zwei Datensätze vorhanden sein. Bei nur 1 wird die Gruppe nicht gelistet, bei 3 oder mehr werden die ersten zwei gefundenen Datensätze verwendet.

Gruß

Christian
Bitsqueezer
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 7219
Registriert: 21. Jun 2007, 12:17

Re: 2 Abfragen einer Tabelle in Endlosformular bearbeiten

Beitragvon incoggnito » 17. Okt 2019, 13:27

Danke für die Ergänzung, da hab ich heute wieder einiges dazu gelernt.
Ich verwende nun übrigens die einfachere Variante eine Tabelle zu erstellen.
incoggnito
Im Profil kannst Du frei den Rang ändern
 
Beiträge: 3
Registriert: 17. Okt 2019, 08:42


Zurück zu Access Forum (provisorisch)

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste