Office: (Office 2013) Im Unterformular mehrere Datensätze auswählen

Hallo Josef,

Code:

Das Problem hatte ich schon mal gehabt und das hat so ohne weiteres nicht funktioniert. Da ich Remote-MySQL verwende. Da hattest du in einem anderen Thread mir empfohlen gehabt, dass über eine Abfrage zu händeln. So hatte es ja auch funktioniert.

Nun würde ich gerne zu dieser Abfrage quasi noch durch den Nutzer eine "WHERE-Klausel" hinzufügen wollen.

Gruß
Daniel

 

Wenn du nur eine Where-Klausel anfügen willst, dann passt der Vorschlag mit der Filtereigenschaft.

Falls die SQL-Anweisung geändert werden soll, weil die zu Filternden Felder nicht im Select-Teil vorkommen sollen o. ä. musst du eben die QueryDef ändern und dann das Subform aktualisieren.

Anm.: falls du ein Formular in Datenblattansicht verwendest, würde auch das Ändern von RecordSource funktionieren.


/edit:
Falls die Spaltennamen nicht geändert werden, funktioniert bei mir auch die Variante mit RecordSource bei einem Subform mit einer Abfrage als Herkunftsobjekt.


mfg
Josef

 

Okay und wie mache ich es, wenn ich einige tausende Datensätze habe, dass das am Anfang durch Überladung nicht bremst, bis der Formular geladen wird?

Gruß
Daniel

 

Was macht man, um an Anfang keine Datensätze zu zeigen?
... where 1 = 0
*wink.gif*

Eventuell könnte man auch noch mit der LinkMasterFields- und LinksChildFields-Eigenschaft des Subform-Controls experimentieren.
Das Problem ist nur generell, dass du die üblichen (einfachen) Wege nicht einsetzen willst, aber für die etwas komplexeren Wege einfach die Grundlagen fehlen. Allerdings verwirfst du generell gerne einen Lösungsansatz, wenn du der Meinung bist, dass es "nicht funktionieren wird" (allerdings ist diese Meinung aus meiner Sicht oft nur auf Vermutung und nicht auf Wissen/Erfahrung basiert.)

Ich kann dir mangels Wissen, wie deine Anwendung aufgebaut ist, nur Wege zeigen. Ausprobieren, verbessern und bei Bedarf in der Hilfe/MSDN usw. nachlesen, um Details zu klären, musst du selbst, da du dein Vorhaben am besten kennst.

mfg
Josef

 

Okay ich versuche das mal mit QueryDef und RecordSource.
Weil ich hatte das Problem hiermit gehabt:
Code:

Das mit Where 1= 0 ist ja mal interessant. Könnte man als alternativ so handhaben.

Ich probiere das alles mal aus und berichte euch wie weit ich damit gekommen bin.

Gruß
Daniel

 

Den ODBC-Connection-String sehe ich nicht so als große Problemquelle.

Versuche einmal folgendes Beispiel:

Ein gespeichert Access-Abfrage "DummyQdf"
Als Sql-Anweisung verwendest du für die Abfrage:
Code:

... diese Abfrage wird benötigt, damit im Subform die passenden Spalten definiert sind.
Diese Abfrage weist du dem Subform im Formularentwurf zu.

Per VBA erstellst du den eigentlich benötigten SQL-Text und weist diesen dann an die RecordSource-Eigenschaft zu.

Code:

.. das ist jetzt alles ungetesteter Luftcode, aber die Vorgehensweise ist hoffentlich erkennbar.

mfg
Josef

 

Hi,

oder einfach nur

 

Hallo Leute,

ich bekomme hier wieder mal einen Fön und brauche euer Hilfe.

Ich bekomme immer wieder urplötzlich einen Formularfehler der für mich unlogisch und unerklärlich ist. Und gestern lief alles soweit einwandfrei und habe am Code nichts gemacht.

Egel welchen oder auch nur einen einzigen Formularereignis ich definiere, bekomme ich folgende Fehlermeldung angezeigt:

"Sie haben als Einstellung der Ereigniseigenschaft den Ausdruck Bei Aktivierung eingegeben. Dieser Ausdruck hat einen Fehler verursacht: Deklaration der Prozedur entspricht nicht der Beschreibung eines Ereignisses oder einer Prozedur mit demselben Namen. USW.

Dabei ist nur der Rumpf der Ereignis definiert. Die Prozedur ist komplett leer bzw. auskommentiert und bekomme trotzdem diesen s.... angezeigt.

Kann mir hierbei jemand helfen?
Stehe voll im Schlauch :-(

Gruß
Daniel

 

Servus Crashbreaker,
1. Optionen...Komprimieren/Reparieren.
oder
2. neue leere DB erstellen und alle Objekte (Formulare, Reporte, Abfragen, Tabellen, Module, Makros...etc.) importieren.

 

Warum das?
Scheint mein Access kaputt zu sein?

 

Access verschluckt sich öfters beim Entwickeln einer DB.
2. neue leere DB erstellen und alle Objekte (Formulare, Reporte, Abfragen, Tabellen, Module, Makros...etc.) aus der defekten DB importieren.

 

Was für eine scheiß Entwicklung von Microsoft. Hätte ich mich auch gewundert, wenn etwas reibungslos verlaufen würde.

Noch ein weiterer Kritikpunkt, warum man lieber andere Programmiersprachen auswählt.

Scheiße ... oh man ... könnte mich voll ärgern ...

Wie gehe ich genau dein 1. Vorschlag durch?

Wo finde ich die Reparaturfunktion?
Vielleicht habe ich glück und kann das so beheben.

Gruß
Daniel

 

Access ist keine Programmiersprache, sondern eine Datenbank, welche per Visual Basic for Applications (Programmiersprache VBA) sehr individuell programmierbar ist zu den zusätzlich schon eingebauten vielen Features.
Bei all den Programmierversuchen und Entwicklungen einer DB versucht Access, diese alle im Hintergrund sich zu behalten.
Irgendwann wird das zuviel und man sollte immer wieder mal die DB "entschlacken".
Je nach Accessversion findet man das in den Optionen unter dem Menüpunkt Komprimieren/Reparieren.
Sollte das nicht funktionieren, hilft es, die nächste Empfehlung meinerseits anzugehen.

 

Hallo,
Deine Fäkalsprache ist völlig unpassend hier, es liegt nämlich nicht an MS bzw. Access sondern ausschließlich an Dir.
Wenn Access wirklich so schlecht wäre, wie Du das hier darstellst, wäre von Access längst nichts mehr zu sehen.

Für die Grundfunktionen von Access muss man gar nichts programmieren. Korrektes Datenmodell vorausgesetzt. Wenn das nicht stimmt, muss oft durch erhöhten (und im Normalfall unnötigen) Programmieraufwand das ausgemerzt werden, was man durch ein falsches Datenmodell erschwert hat. Das Programmieren kommt erst dann richtig ins Spiel, wenn es um die Benutzerführung geht.
Und da ist Access mit Sicherheit eine einfache und komfortable durch VBA steuerbare Anwendung, die dann auch stabil läuft.
Du als Entwickler hast den größten Anteil daran.

zeige dies Prozedur trotzdem mal hier (vollständig).

 

Hallo,

nun ja ich weiß das Access keine Programmiersprache ist. Das war ja auch eher auf VBA bezogen, nur mit dem Bezug zusätzlich auf Access.

Mein Ärger war ja nicht auf euch gerichtet, sondern rein auf Access. Daher bitte nicht falsch verstehen. Habe mich nur darüber verärgert, was ja verständlich ist, hoffe ich. Bin euch dankbar und sehe ja, dass ihr mir helfen wollt.

Zur Kritik:
Nun ja man könnte hier stundenlang darüber philosophieren was Access gut kann und was nicht. Fakt ist, dass solche einfachen Dinge nicht so ohne Weiteres realisierbar sind. Siehe dazu die obigen Beiträge. Die Erwartungen bei Implementierungen von einer DB soll NICHT auf Mühe und Notumbiegungen durch experimentieren gestützt werden, um die Nutzbarkeit und das Optische für den Nutzer annähernd so angenehm wie möglich zugestalten. Das ist nicht der Sinn des Erfinders. Bei anderen Sprachen, Entwicklungsumgebungen oder was auch immer, sind zu mindestens gewisse Sachen standardisiert oder bieten zumindestens dafür eine vereinfachte Lösung an. Ich musste mir zur Realisierung der Darstellung eine Dummy-Tabelle erstellen um diese Lücke zu umgehen. Dabei existiert Access schon Jahrzehnte und Microsoft hätte inzwischen eine sehr einfachere Lösung dafür anbieten können. Naja wie ich schon sagte, Meinungen können in zig verschiedene Richtungen gehen. Der eine findet das gut, der andere das. Ärgerlich ist es für jemanden der aus einer anderen Entwicklungsumgebung kommt und andere Standards gewohnt ist. Da hat man dann eine Mindestvoraussetzung zu einer DB und muss den Rat nicht durch Umwege wie hier der Fall ist neu erfinden.

Ich werde den Vorschlag Nummer 2 von @Ohrkester ausprobieren und hoffen, dass es danach funktioniert.
Solche unnötigen dinge hätte man dem Entwickler ersparen können. Zu mal das Meiste eh auf Codebasis gestützt ist (zu mind. bei mir).

@Klaus
Klar, kann ich machen:
Code:

Gruß
Daniel