Office: (Office 2010) Transactions

...was ich vergessen habe ist, beim schliessen des Form muss die tblCange noch gelöscht werden!
PS: Verstehen und nicht Missverstehen ist auch eine Kunst, die nicht jeden gegeben.

 

... mir ist noch etwas eingefallen, diesen Save-Button könnte man schon einsetzen.
Für das löschen der tblCange. Diese Buttons sichtbar/unsichtbar zu erstellen wäre auch noch eine Idee.

 

...funktioniert noch nicht wie es soll, muss es mir noch einmal genauer ansehen!

 

...so, jetzt funktioniert es richtig!

 

Ist schon klar:
Ich schätze Ebs' antworten bereits jetzt, aber ihr dürfts mir nicht übel nehmen, dass ich so reagiert habe. Wenn einer ohne eine kompetente Eingabe oder einen konstruktiven Beitrag die Gehirnmasse zwischen meinen Ohren infrage stellt, dann seh ich halt rosa bis rot. *wink.gif*

Ok, @Kyron: Dein Beispiel wirkt eher seltsam. Wenn ich einen Grundbestandteil hinzufüge und dann auf Cancel clicke ist er trotzdem noch da. Klappt also wohl nicht so ganz. Und wo sind meine anderen Bestandteile abgeblieben?

@markus: Lustig find ichs auch. *biggrin.gif* Aber ich hab mir vorgenommen, diesen Kram zu verstehen. Also versuch ich wirklich ernsthaft eine Lösung zu finden, und das mit den disconnected Recordsets scheint mir durchaus noch am plausibelsten.

Wenn also ado2.8 immer zur Verfügung steht, werd ich mich mal an einer Lösung versuchen.

 

...*grins dachte, diese Kleinigkeit sei dir selber gegönnt zu erstellen,
anscheinend zu schwierig.
Wobei ich es noch geschrieben habe, dass ich diese Möglichkeit nicht eingefügt habe!
Aber, so einem freundlichen Mitglied hilft man ja gerne!

PS: Rücksetzung für das Hauptformular habe ich nicht eingefügt,
werde ich auch nicht...ok?

Wie kann ein Beispiel eher seltsam wirken?
Finde ich schon sehr lustig deine Antworten um nicht zu sagen beleidigend!

Jetzt habe ich es erst gelesen...
welchen Grund soll es geben, dass ich die anderen beiden Formulare auch erstelle?

 

\@Kyron9000, er hat wohl nicht die Version V2 verwendet. Die ganze Arbeit bringt auch nichts, da er dann eh alles anders einsetzt. Das Prinzip ist aber für jeden erkennbar. In der Realität steigt die Komplexität natürlich etwas an, aber wol ist ja kein Anfänger.

@wol,
da du ado recordsets kennst, bist du ja in der Lage selbst mit disconnected RS zu testen. Vor dem Testen aber einfach mal logisch durchdenken hilft zu erkennen, dass das nicht so trivial ist. Auto ID geht dann ja nicht - woher soll die ID auch kommen?

 

\@Markusxy

denke, die V2 hat er schon getestet, die V1 hat ja wirklich nicht funktioniert...
da war es schon spät *Smilie
Die V2 hat mit vorhandene DS funktioniert, die V3 funktioniert auch mit neu erstellten DS...
mich hat das Thema interessiert, deshalb erstellt... sonst eh nicht *wink.gif*

PS: auch mit einer Transaktion (ADO) musst die Daten genauso sichern,
wie sollst sonst die alten Daten zurückbringen?!
Da setze eben einen Sicherungspunkt und dann kannst zurückrollen.
Geht aber mit DAO auch. Ob schneller oder langsamer, kA.

 

\@Markus

ID's kannst du damit verwalten. Nutze ich seit Jahren. Habs allerdings auf ADO angepasst. *Smilie

http://dbwiki.net/images/c/cd/AccSampleParameter.zip

VG
trekking

 

\@wol,
Ich hab mir jetzt das Modell disconnected mal kurz bezüglich ID angesehen.
Es ist doch viel einfacher als ich dachte.

Die Daten werden einfach in ein ADO RS geladen und die Connection auf Nothing gesetzt und das RS an das Form gebunden.

Bei einem neuen Datensatz wird die ID im BeforeInsert Event gesetzt.
Ansonsten ist alles wie bei einer "normalen Bearbeitung".

Cancel: einfach das Recordset wie zu Beginn neu laden.
Save: Abgleich mit den Daten aus der Tabelle.

Eigentlich ganz easy, und viel einfacher wie jede andere Lösung.

 

OT
@markus ein paar Fallstricke gibt es schon.
z.B.: http://ms-office-forum.net/forum/sho...ht=updatebatch

würde ich also nicht blanko unterschreiben.
Kommt - wie fast immer - auf den Anwendungsfall an.

 

Ok, hier kommt Schlag auf Schlag.

@Kyron: ich werd V3.0 gleich mal testen.
Ansonsten hab ich gedacht, wenn die Recordsets disconnected sind und die Daten verworfen werden sollen, dann mach ich halt einen requery und schon sind die geänderten Recordsets dahin.
Äh, ich wollte nicht beleidigend sein, eher lustig. Wüsste aber nicht, wo das geschehen sein soll...

Auch an @markus. Schlägt in dieselbe Kerbe. Ich dachte auch, das sei die einfachste Lösung.
AutoIDs hab ich zum Glück hierbei nicht.
Wisst ihr, ich werds einfach mal morgen probieren. Heute Nacht bin ich zu fertig, das noch zu implementieren, aber morgen... schaun wir mal.

 

In dem Beispiel geht es ja um Batch Aktualisierung.
Nach meiner Erfahrung kannst du das mit einem Access Form vergessen.

Wenn du die Daten über ein Form einfügst, wird ja automatisch BatchUpdate ausgelöst und es ist keine Synchronisierung mit der Tabelle mehr möglich.
Macht man es per VBA werden die Daten im Form nicht angezeigt.

Da ich aber bei ADO Endlosdarstellung im Regelfall keine Access Forms verwende musste ich es zuerst testen. Mit Abgleichen meine ich abgleichen per Loop und nicht UpdateBatch. Aber das sollte wohl jeder der sich Programmierer nennt schaffen.


Edit:
Josef's Vorschlag zwei RS zu führen - oder auch ein Protokoll der Änderungen (das Batch RS ist ja auch nichts anderes als ein Protokoll von Änderungen) sind auch alles Möglichkeiten. Schlussendlich kommt sich alles auf's gleiche raus und je nach Anwendungsfall ist die Performance und der Speicherbedarf unterschiedlich.

 

Hallo,

ok, dann sehe ich es auch so *Smilie

 

Wobei dann die Varianz noch etwas höher ausfallen dürfte, wenn man sich das "ist eben so"-Datenmodell von wof ansieht.
Wenn eine Zutat in der n-Tabelle einer 1:n-Beziehung mit der Rezeptetabelle als Primärschlüssel geführt wird und somit inklusive der Mengenangabe nur genau einmal über alles verwendet werden kann, dann dürfte das in Hinsicht auf Rezepte erstellen und variieren ganz besondere Effekte mit sich bringen und schon daraus einen Änderungsdruck generieren statt eine Kopie des Rezeptes ziehen zu können und da etwas zu tun.
Ob man nun mit dem Aufsetzen von nichteinfachen Maßnahmen auf das Ganze - im Beispiel sind es mindestens drei Unterformulare sowie einige weitere noch unberücksichtigte Tabellen - zu einer "erwarteten" Rezepteverwaltung kommt? Da wächst die Erwartungsspannung.