Master-Detail-Formular

[Josef P.]

Dann hab ich dich falsch verstanden.
Bei "Recordsource zuweisen" bin ich davon ausgegangen, dass du nur den Text der Recordsource-Eigenschaft übergibst.

Dein gezeigter Code passt. Kann es sein, dass du nach Load die Datenquelle änderst?
Falls dir die Beispiel-Datenbank im verlinkten Artikel zu wenig hilft, erstell bitte eine kleine Beispiel-Anwendung, dann kann ich dir das besser zeigen.

mfg
Josef

[crystal]

Hallo Josef,

nochmal Dank für deine Geduld.

Falls dir die Beispiel-Datenbank im verlinkten Artikel zu wenig hilft, erstell bitte eine kleine Beispiel-Anwendung, dann kann ich dir das besser zeigen.

Welcher verlinkte Artikel?

Ich habe schon eine Bsp-DB erstellt (acc2016).

Vielleicht hilft sie, den Gordischen Knoten zu durchschlagen...

Gruß,

crystal

[Beaker s.a.]

Hallo crystal,
Haber es mir mal angeschaut.
Es fehlt bis jetzt die Funktion zur Synchronisierung.
Wobei ich die Frage stellen möchte, ob es sinnvoll ist in einer Einzelansicht nach
einem DS zu suchen (aus Anwendersicht). Welches Ereignis welchen Controls
willst du da nutzen?
Zum Synchronisieren an sich:
Weiss nicht wie Josef es machen wird(würde), ich würde bei deinem Konstrukt das
HFo auf den ausgewählten DS positionieren und dann in UFo2 die Link-Felder setzen.

gruss ekkehard

[DF6GL]

Hallo,


wenn Du zwei UFOs, die sich aufeinander beziehen, in einem HFO benutzt, so musst Du auch die (richtigen) Recordsets der UFOs benutzen und nicht das Recordset des HFOs (das hier keine Rolle spielt).

Andererseits verstehe ich Deine Problematik(en) nicht. Ich empfinde es so, als wolltest Du andauernd die Eigenheiten/Funktionalitäten von Access verbiegen....(mit API  und/oder Vergleich mit VB oder anderen Programmiersprachen.)


Anbei die DB mit Formular1 (zwei verbundene UFOs in einem HFO) und Formular2 (ein UFO in einem HFO im Endlos-Modus) .

Hierfür ist keine einzige Zeile Code nötig.

Natürlich ist  die Recordset-Methode auch einsetzbar und  zeigt die Hintergründe klärend auf.

[Josef P.]

Hallo!

Der Fehler im Code von mir war der Teil mit den Verknüpfungsfeldern. Wenn man diese ändert wird anscheinend die Datenquelle erneuert.

Im Anhang ist noch die Variante mit nur einem Unterformular und der Datenanzeige im Hauptformular.
Wenn man das selbe Recordset verwendet, kann man in beiden Formularen navigieren und die Datensatzanzeige in den Formularen stimmt ohne Zusatzaufwand überein. Das kann ein Vorteil sein - wenn man diese Funktionalität nutzen will. Das kann aber auch nicht passen, wenn man im Detailformular nur einen Datensatz haben will.

Welcher verlinkte Artikel?

Dieser:

Vielleicht hilft dir folgender Beitrag: Formulare synchronisieren

mfg
Josef

[crystal]

Hallo Franz,

vielen Dank für deine Test-DB. So hatte ich mir die Funktionalität vorgestellt.

Andererseits verstehe ich Deine Problematik(en) nicht. Ich empfinde es so, als wolltest Du andauernd die Eigenheiten/Funktionalitäten von Access verbiegen....(mit API  und/oder Vergleich mit VB oder anderen Programmiersprachen.)

Naja - das wäre ja durchaus legitim, wobei ich Access nicht verbiegen möchte, sondern nur nach Funktionälität suche... Mein Vergleich mit anderen Programmiersprachen ist insofern gerechtfertigt, als eine simple google-Suche nunmal Treffer aus anderen Umgebungen liefert. Zudem ist es ja nicht mein Problem, dass Microsoft parallel verschiedene Implementierungen "pflegt" und es z.B. bisher nicht geschafft hatt, Access bzw. VBA .Net-kompatibel zu machen. Dass man manchmal ohne API-Funktionen nicht auskommt, ist anschaulich in meinem Thread "Natürliche Sortierung" dokumentiert. Und es gibt sehr viele Beispiele mehr, weshalb es nötig war oder noch ist, API-Funktionen zu bemühen, weil Microsoft keine entsprechenden Funktionen in VBA zur Verfügung gestellt hat.

Ich bekenne, dass ich Access zum rapid protyping gerne benutze, habe aber auch Erfahrung mit anderen Umgebungen, die insgesamt ausgereifter und vollständiger zu sein scheinen...

Meine häufige Kritik an Access beruht letztlich auf der Tatsache, dass Microsoft immer wieder Funktionalität nachgerüstet hat, die man eigentlich schon lange hätte erwarten können. Im Kern aber gibt es nur relativ geringe Unterschiede zwischen Acc2016 und etwa Acc2000. Sorry, aber so sehe ich das eben.

Und sorry, dass ich jetzt wieder allgemeine Statements abgegeben habe, aber ich wurde dazu ja geradezu aufgefordert (siehe Zitat oben).

Gruß,

crystal

[crystal]

Hallo Josef,

deinen Link habe ich einfach übersehen. Ich bitte um Entschuldigung.

Danke für deine Test-DB und deine vielen Antworten an diesem trüben Sonntag!

Grüße,

crystal

[Josef P.]

[OT]

bisher nicht geschafft hatt, Access bzw. VBA .Net-kompatibel zu machen.

Access und .net sind indirekt kompatibel, da man mit .net auch mit dem COM-Interface arbeiten kann sowie COM-dlls erzeugen kann, die man dann wiederum in Access/VBA verwenden kann.

Ich nehme aber an, dass du meinst, dass du in Access statt VBA eine .net-Sprache verwenden kannst - du willst in Access statt mit VBA in einer .net-Sprache programmieren oder in Access native .net-dlls einsetzen. Das das nicht so einfach geht, sollte aber verständlich sein.
Wie groß glaubst du, wird der Aufschrei der Anwender sein, wenn Microsoft in der nächsten Version VBA (VB6/COM) abdrehen und ein VBA.net einführen würde? (Also COM nicht mehr unterstützen würde sondern nur noch .net?)
Damit wäre die Abwärtskompatibilität aufgehoben und alle alten Excel-Dateien mit VBA-Code würden nicht mehr laufen. Auch wenn es einen brauchbaren Konverter geben würde, wäre das mit Aufwand beim Kunden verbunden. Das wäre ein "perfekter Marketing-Schachzug", um die neue Version nicht zu verkaufen.
Also würde dem Office-Entwickler-Team nur eine Variante bleiben: beide Entwicklungsplattformen unterstützen. An so etwas glaube ich aufgrund der damit verbundenen Kosten nicht.
Ich würde mir zwar so etwas auch wünschen, aber mehr als ein Wunsch an das Christkind wird das meiner Meinung nach nicht werden.

mfg
Josef

[crystal]

Lieber Josef,

natürlich hast du mit deinen Argumenten Recht. VBA einfach durch eine .net-Sprache zu ersetzen ist natürlich weder sinnvoll noch möglich.

Es wäre m.E. aber an der Zeit, ein Access-ähnliches Produkt aufzusetzen, das auf neueren, objektorientierten Technologien beruht. Es muss ja dann auch nicht mehr den Namen Access tragen. Es scheint mir auch so zu sein, dass Microsoft die Weiterentwicklung von Access nicht mehr mit höchster Priorität betreibt, was durchaus auch für andere Office-Produkte gelten mag. Immerhin ist das Office-Paket inzwischen in die Jahre gekommen und wegen des ewigen Zwangs zur Abwärts-Kompatibilität aus den prozeduralen Ansätzen der ersten Version nicht herausgekommen.

Gleichviel - genug geredet über Strategien oder Nicht-Strategien von Microsoft. Wir werden und müssen mit Access in der heutigen Form sicher noch ein paar Jahre leben und Dank solcher Experten wie dir wird es möglich bleiben, Probleme zu lösen. Naja - ab und zu kommen dann vielleicht ein paar seltsame Fragen von Leuten wie mir, aber dadurch wird Access ja nicht schlechter.

Herzliche Grüße, auch an die anderen,

crystal

[Josef P.]

[ein wenig OT muss sein. ]

Es wäre m.E. aber an der Zeit, ein Access-ähnliches Produkt aufzusetzen, das auf neueren, objektorientierten Technologien beruht.

Es gab einmal einen Versuch mit LightSwitch. War aber vermutlich nicht der Renner.

Wir werden und müssen mit Access in der heutigen Form sicher noch ein paar Jahre leben

Kennst du https://access.uservoice.com/ ?
Da kannst du ein wenig verfolgen, was vom Access-Team an Vorschlägen angenommen wird und auch selbst mit abstimmen bzw. Vorschläge machen.

Naja - ab und zu kommen dann vielleicht ein paar seltsame Fragen von Leuten wie mir, ...

.. und das ist gut so.

mfg
Josef