Office: (Office 2010) Transactions

Ich bin mir auch nicht sicher, ob er weiß was er sich mit dem Datensalat antut. Seit ich aber weiß, dass die DB im Thread nicht die Realität abbildet, mache ich mir da keine Gedanken.
Das wird sicher lustig, und jeder kann was lernen.

 

OT

Was verwendest du?

 

Tut mir leid, euch da auf die Folter zu spannen. Ich bin noch nicht dazu gekommen, das Konzept mit den disconnected recordsets in meiner Beispieldatenbank zu testen.
Ich beabsichtige aber, das noch in den nächsten paar Tagen zu tun. An die Originaldatenbanken komm ich eh erst nächstes Jahr wieder ran. aber bis dahin beabsichtige ich genau zu wissen, was ich tu. :-)

Und ich hoffe, damit genug zur allgemeinen Belustigung beizutragen. *biggrin.gif*

 

\@Kyron: Bin leider erst jetzt dazu gekommen, Deine V3 zu probieren. Bin auch jetzt erst richtig dahintergestiegen, was Du da eigentlich machst: du speicherst die Änderungen in einer Tabelle, um sie bei Cancel rückgängig machen zu können. Das ist außerordentlich clever und eine tolle Idee. Wenn ich aber eine Zutat lösche, isse fort. Da nutzt kein Cancel mehr.

 

Ich versuch mich gerade an den disconnected recordsets.
Aber schon scheitert mein unerfahrener Access-Verstand daran, die erstellten Recordsets den Unterformularen zuzuordnen. :-/
Welche Eigenschaft des Unterformulars nimmt denn nun die neue Datenquelle entgegen? Es gibt keine .RecordSource und keine .DataSource Eigenschaft und die Eigenschaft .SourceObject will meinen ADODB.Recordset nicht haben. ebenso wie ufo.Form.RecordSource oder ufo.Form.Recordset. Ich kapiers nicht, ehrlich gesagt.
???

 

\@wol
Unterformulare: Du erstellst einfach drei ganz normale Formulare.
Die Formulare kannst du dann einfach in ein anderes Form reinziehen, dann sind es Unterformulare.
Oder du fügst ein Unterformular Steuerelement ein und dann kannst du das Formular angeben. So könnte man natürlich ein Formular auch mehrfach mit verschiedenen Datenquellen verwenden.

Rückgängigmachen mit Kyrons Vorschlag:
Dafür müsstest du das Protokoll so erweitern, dass das eben auch funktioniert. Sollte für dich wohl kein Problem sein, zumal du jetzt das Konzept verstehst.

LG M

 

Was? Also jetzt mal langsam. Ich hab noch überhaupt keine Vorgehensweise gewählt. Ich bin immer noch am Rumprobieren, was wohl am Besten ist.

Ich reduziere meine Frage mal auf ein ganz einfaches Topic:
Ich hab da ein ADO Recordset.
Und da ist ein Unterformular, dessen deutsches "Herkunftsobjekt" bisher ne Tabelle war.
Ich möcht jetzt, dass dessen Herkunftsobjekt mein "disconnected recordset" ist. Wie mach ich das?
ufo.SourceObject will meinen ADO Recordset nicht haben. Was muss ich tun?

 

Und... was das Beste ist:
Wenn ich das mache:
Set rsG.ActiveConnection = Nothing (nachdem ich den Recordset geöffnet hab)
bekomme ich ne Fehlermeldung:
"Operation is not allowed when the object is open."
Ich versteh nur noch Bahnhof.

 

\@Markus,

der damalige Fall - wenn ich mich recht erinnere ging es um eine Auswahlliste
für Serienmails/-fax, ist ja auch schon 4 Jahre her - hat mit den Anforderungen,
wie ich sie hier verstehe nicht viel gemein.
Die Batchaktualisierung kam damals auch nur nebenbei zur Sprache, weckte
jedoch mein Interesse, um die Anwendungsmöglichkeiten von disconRS
eingrenzen zu können.

Da ich das gesamte Ansinnen wirklich nicht nachvollziehen kann ...
-Martini mit Kirsche / Olive wären bei mir zwei Rezepte
-Wer Daten ändert, sollte sich vorher Gedanken machen oder eine strickte
Historisierung aufbauen (dann kann man auch mal 3 bis x Schritte zurückgehen).
... und wenig Zeit habe, mache ich mir zum eigentlichen Thema weniger Gedanken.

Wenn Ufo-Steuerelement und Steuerelementinhalt nicht unterschieden werden (können),
sind DisconnRS vielleicht noch ein wenig zu hoch angesiedelt, zumal sie sich in Formularen
machmal wirklich etwas zickig verhalten.

Vor dem Hintergrund, würde ich dem TE eine Lösung mit temp Tabellen empfehlen.
Und damit ist Alfred doch schon weit gekommen (Hab mir die Lösung nicht angesehen).?

BTW: Bekomme ich noch eine Antwort auf #92?