Office: (Office 2010) Transactions

@ebs: Unverschämtheit! *mad.gif* Was nimmst Du Dir denn hier heraus?
Ich arbeite mit VB seit es 4.0 gibt! Objekte sind mir selbstverständlich ein Begriff und der Umgang mit F2 ist ein täglich Brot für mich. (Ich kann Zyniker nicht ausstehen, also bleib besser weg, wenn Du noch mehr solcher schmähender Bemerkungen für mich erübrigen willst.)

@alle anderen:
Wenn ichs recht verstehe, sind die Access-Formulare irgendwie vornedran, wenns um Datenzugriff zu den Tabellen geht. Transaction wirkt hier offenbar nicht. Ok. Also müsste ich ein ungebundenes Fromular benutzen mit Recordsets (was dann meinen VB6 Erfahrungen am ehesten gleichkommt). Das wird kompliziert...

Ach ja, @ebs:
Was vor dem Punkt steht ist DAO.DBEngine, falls das irgendeinen Sinn zwischen Deinen Ohren ergibt.
Ich hab also aufgerufen:
DAO.DBEngine.BeginTransaction
dann werden Änderungen an bis zu 4 Tabellen ausgeführt
dann kommt bei Cancel: DAO.DBEngine.Rollback.

 

Transaktionen haben für mich etwas mit Direktzugriffen auf das Backend zu tun, sprich wenn man z.B. einen qualifizierten Import vornimmt und da Daten in mehreren Tabellen des eigenen Datenmodells unterzubringen sind. Das ist automatisierte Massendatenverarbeitung, und wenn da der Ablauf durch einen Fehler unterbrochen wird, erhält man im Backend einen inkonsistentem Zwischenzustand, was unbefriedigend und vor allem schwer auflösbar ist. Über einen Rollback erhält man einen definierten Zustand, nämlich den Ausgangszustand. Damit hat man die Möglichkeit, nach Identifizierung des Fehlers den Vorgang zu wiederholen.

Spielereien über Editierungen im (gebundenen) Formular haben mit Massendatenverarbeitung nichts zu tun und wären damit aus meiner Sicht auch nicht Spielwiese von Transaktionen. (Nicht alles, was technisch umsetzbar wäre, ist auch sinnvoll in einer konkreten Verwendung: Man steht am Abgrund, und man könnte springen ...).

Für die Arbeitsweise Eingeben, Testen, Gucken und ggf. Übernehmen gibt es mehrere Spielarten, je nach konkreten Rahmenbedingungen.
1) Man könnte das Backend bzw. ausgewählte relevante Tabellen vorher sichern und so nach Widerruf der Editierungen den Ausgangszustand wiederherstellen. Logischerweise muss man da beim Spielen bleiben und darf nicht andere gewünschte Aktionen einmischen.

2) Umgedreht könnte man sich die relevanten Tabellen als Temp-Kopie ziehen, darin arbeiten und bei Entscheidung zur Übernahme die Datensätze in die Stammdaten übernehmen. Dann mit Transaktion.

3) Das Auswerten einer erfassten Änderungshistorie wäre denkbar.

4) Spielwiese für VBA- und Klassenfans: Man könnte den Vorgang (Hauptdatensatz und verknüpfte Detaildatensätze) in eine Klasse übernehmen, dort entsprechend hin- und herverarbeiten sowie dann die Ergebnisse bei Wunsch und Drang wieder in die Stammdatentabellen zurückführen.

5) Ein denkbarer Mehrnutzerbetrieb stellt auch gewisse Anforderungen.

@wof: Nein, keine Unverschämtheit meinerseits. Aber ausgesprochene Wahrheiten können durchaus weh tun. Da Du Dich auskennst (über Worte hinaus), hast Du bemerkt, dass DAO und die DBEngine keine Objekte eines Accessformulares sind und daher höchstens parallel zu verwenden sind. Wer Ahnung hat, darf das auch zeigen.
Wenn Hinweise und Antworten nicht über ein Feedback zumindest in Nachfolgehandlungen wahrnehmbar sind trotz mehrfacher Wiederholung, dann sollte man sich nicht beklagen, dass andere auf den Gedanken kommen, dass Hinweise nur ins Nirwana fallen (= umsonst sind).

Da ich mich aber wiederholt wiederhole in Deinen Themen, bemühe ich mich, Dich nicht weiter zu belästigen. Willkommen in der I-Liste.

 

Hallo zusammen,

imho gibt es hier
Undo in Formularen und Unterformularen - Access im Unternehmen
ein Beispiel, welches genau das beschreibt, was gewünscht wird.

Ich weise darauf hin, das derart lange offene Transaktionen aufgrund der
Sperrmechanismen praktikabel ausschließlich in Singleuser-Anwendungen benutzt
werden können.

 

Dazu muss ich sagen, dass ich nur ein einziges Formular für die Erfassung der Daten verwende. Dieses konfiguriert sich zur Laufzeit gemäß den Metadaten der Abfrage oder Tabelle.
Weiters noch ein Form mit einem Datagrid, welches sich genauso zur Laufzeit konfiguriert, so dass ich es für jede Tabellen einsetzen werden kann.

Zur Bearbeitung öffne ich dann aus dem Grid oder durch einen direkten Aufruf besagtes Detailform.
Wenn es dann ein "UF" geben sollte, welches 1:N/M:N Daten darstellt, dann öffnet sich dieses Automatisch in einem Grid.

Speichern:
Gespeichert wird, wenn der User speichern drückt.
Das ist erst möglich,wenn alle Voraussetzungen dafür erfüllt werden.
Vorzeitiges abbrechen geht immer. Die Daten werden im Detailform bis zum Speichern in einer Klasse gehalten.

Da es in Access nicht möglich ist zur Laufzeit Steuerelemente zu erstellen, überlege ich mir schon seit einiger Zeit, diese beiden Formulare mit MsForms zu erstellen. Das ist auch eine der wenigen Möglichkeiten die Daten in Access sicher zu kapseln. Da ich mich aber auch grade für .net fit mache habe ich etwas wenig Zeit dafür.

 

Die Frage ist doch, wo ist der Unterschied, ob das RS vom Form erstellt und zugewiesen wird, oder ob das RS per VBA erstellt und dem Form zugewiesen wird. Weil dieser Unterschied bestimmt, ob die Transaktion greift.

Nach meinem Verständnis werden Datenänderungen vom Formular ins Recordset geschrieben und via Recordset in die Datenbank.
Aber das wird so wohl nicht stimmten, wenn es ein Recordsource gibt.
Irgendwie scheint die Jet diesen Mechanismus wohl zu umgehen.
Aufklärung könnte das wohl nur MS leisten.

 

\@Markus

Danke für Deine Antwort. Sportlich alles mit einem Formular zu machen. Habe in meinen Anwendungen auch teilweise "formular sharing". Allerdings geht das meist nicht, da zuviele unterschiedliche Funktionen abgebildet werden. bei ähnlichen Formularen auch nicht zwecks der Übersichtlichkeit und dem Eventhandling.
Das mit dem Speichern mache ich ähnlich. Allerdings speichere ich meist nicht in einer Klasse zwischen sondern speichere wenn der User anfängt DS im UF anzulegen schon physikalisch. Sagt der User dann am Schluss, dass er nicht speichern will, lösche ich die Daten (oder setze Sie auf gelöscht zum Historisieren, je nach Anwendung). Manchmal speichere ich die Daten auch in einem Disconnected Recordset in einer Klasse. Das ist auch eine Interessante Möglichkeit.
Das mit den Steuerelementen nervt mich auch etwas, da ich an einigen Stellen Code-Generatoren beutze umd die ungebunden Formulare einzurichten, würde ich ab und an auch ein Steuerelement erstellen wollen.

Viel Erfolg beim .net lernen. Macht spaß und bietet noch andere Möglichkeiten. Mein bevorzugter Autor ist für VB.net Michael Kofler.

VG
trekking

 

Ja es ist gar nicht so leicht einen Autor zu finden der zu einem passt.
.net macht natürlich Spaß. Es ist halt sehr komplex, daher habe ich es bis jetzt gemieden, aber es nutzt nichts. Und heute geht ohne .net wenig.

Habe gestern mal wieder was in c++ 6.0 nachgesehen. Das gefällt mir persönlich viel besser wie .net, da man viel mehr Bezug zu dem hat was macht. In .net geht der halt ziemlich verloren, was schade ist.
Performance und erforderliche Datenmengen in Objekten sind oft unbekannt und man braucht viel Zeit für das Studium der Schnittstellen, anstatt mit dem Programmieren.

 

\@marsu: In der Tat sieht es so aus, als wäre dieser Artikel genau DIE Antwort auf mein Problem. Ich werd ihn mir später mal genau zu Gemüte führen. Danke. In der Tat habe ich auch in VB6 nur mit Recordsets gearbeitet. Ist die beste Lösung.

@markus+trekking: Auch ich mache gerade eine Umstellung auf .NET durch, die mich oftmals zur Verzweiflung treibt. VB.NET ist längst nicht so elegant und flott wie VB6, an das ich mich so gewöhnt habe. Vieles wird anders gehandhabt, bekannte Properties sind plötzlich anders, es gibt keine ad-hoc-Control-Arrays mehr etc. Ich trauere VB6 sehr hinterher. Schade, dass es nicht mehr unterstützt wird.

@ebs: Wenn man so schlau und klug ist wie Du, ist es erbärmlich, jedmanden, der Deine unvollständigen Aussagen und dubiosen Vergleiche (Nachbars Milch), hinterfragt gleich als dumm hinzustellen. *rolleyes.gif* Offenbar gibt es ja eine kompetente Antwort.

 

OT

Welches Grid verwendest du?

 

Tools & Components · Entwicklertools · DataGrid & Listen

Möchte aber mein eigenes Grid machen, sobald ich das repaint mittels subclassing per VBA umsetzen kann.
Im Moment muss ich noch ein BMP einem Control zuweisen. Geht auch braucht aber mehr Speicher.

 

Eleganz ist nur eine Frage der Gewohnheit.
Performance ist eher eine Frage des Programmierens. Obwohl natürlich das Framework schon eine Rolle spielt. Aber das alte VB ist wohl per Konzept nicht sehr schnell.

Hast du mal mit C oder Assembler gearbeitet?

Ich habe in VBA öfter mal Performance getestet.
Ein einfaches ändern eines Arrays von x() as Klasse zu X()as object, hat in meinem Test mehr als den 10fachen Geschwindigkeitsunterschied gemacht. von 0.271 Sekunden zu ca 3 Sekunden. LateBinding ist ein SpeedKiller. Oder so was wie callbyName, Run "SubName", ist wohl das schlimmste von allem. Das VB6/VBA langsam macht ist das automatische konvertieren - auch z.B. bei COM Schnittstellen, wenn Konvertiert werden muss. All das was bequem ist, kostet sehr viel Zeit. Dieses Prinzip gilt in jeder Programmiersprache. Macht sich natürlich nur bei vielen Durchläufen bemerkbar. Dann aber umso heftiger.

LG M

Edit: Aber da könnte uns sicher Nouba viel erzählen, der zählt hier zu den Top Profis -> und natürlich einige andere auch noch.

 

Deiner pauschalen Aussage bzgl. Geschwindigkeit kann ich nicht ganz folgen und sollte dann auch anhand von Beispielcode belegt werden können.

Dass VB6 beim Kompilieren keine Befehlsanweisungen verwendet, die erst in Prozessoren ab der Jahrtausendwende implementiert wurden, ist eine andere Geschichte.

PS: was denkst Du denn, womit Dein Grid programmiert wurde?

 

Oh ja, ich hab auch schon C und Assembler programmiert. Zeitkritische Laderoutinen und sowas.

Mit flott habe ich aber nicht die Geschwindigkeit des auszuführenden Codes gemeint. (Hab bereits mehrfach festgestellt, dass .NET-Programme in vieler Hinsicht schneller sind als VB6 Kompilate).
Ich meine die IDE und die Handhabung im Designer. In VS.NET dauert es "ewig" (ich meine erheblich länger), bis das Projekt lädt und bis sich was tut. In VB6 geht das alles viel flotter.

Leider wird VB6 wohl bald das Zeitliche segnen, wenn ich Win7 aufgeben muss. Wie ich gesehen habe, ist der VB6 Form-Designer in Win10 kaum noch zu handhaben.

 

Nein, dass sind keine pauschalen Aussagen.
Der angeführte Zeitunterschied war z.B. die Suche eines Objektes anhand einer String Property in einem Array.

100.000 Durchläufe wo ein Objekt aus einem indexierten Array mit ca 50 Elementen nach dem Konzept der binären Suche gesucht wird.

Es musste also etwa 600.000 mal die String Property per LateBinding ausgewertet werden.

Zwischenzeitlich durchlaufe ich nur noch ein sortiertes Array mit Stringpointern, da dauert es nur noch einen Bruchteil der Zeit.

 

ja leider.