Hallo,
weiß jemand, wie man es lösen könnte, daß bei Access 2000 der SQL-String der Abfrage per VBA oder Makro oder ähnlichem verändert wird? Der SQL-String an sich steht in einer Variablen.
Gruß
Thomas
Hi,
Wenn du weisst wie Strings in VB(A) modifiziert werden, weisst du auch wie man das machen kann.
Ansonsten glaub’ ich, musst du etwas detaillierter werden…
Gruss
quaser
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hi,
Wenn du weisst wie Strings in VB(A) modifiziert werden, weisst
du auch wie man das machen kann.
Ansonsten glaub’ ich, musst du etwas detaillierter werden…Gruss
quaser
Hi Quaser,
ich weiß zwar, wie man Strings modifiziert, aber ich habe noch kein Ereignis gefunden, an dem ich diese „String-Modifikation“ anhängen kann. Ich bräuchte hier so etwas wie ein Query_Load-Ereignis, Ich kann aber kein solches finden. Oder anders ausgedrückt, ich habe kein VBA-Modul für die Abfrage, in die ich diese Operation hineinpacken könnte.
Gruß
Thomas
Hallo Thomas
Ich bräuchte hier so etwas wie ein Query_Load-Ereignis
Ich kann aber kein solches finden.
So etwas gibt es auch nicht (also ein Ereignis, das du bei der Abfrage selbst definieren kannst). Aber irgendwie wird die Abfrage ja geöffnet, und diese Stelle musst du finden.
Oder anders ausgedrückt, ich habe kein VBA-Modul für
die Abfrage, in die ich diese Operation hineinpacken
könnte.
Dies könnte z.B. das Open-Ereignis eines Formulars sein, das auf dieser Abfrage basiert. Oder das Click-Ereignis eines Buttons, der das Öffnen der Abfrage durchführt. Oder, oder, oder…
Wie oben geschrieben, eine solche Stelle MUSS es geben, denn die Abfrage wird ja nicht von „Zauberhand“ geöffnet.
Gruss
Peter
Hallo Peter,
das mit der Zauberhand stimmt zwar nicht ganz, aber fast. Diese Abfrage ist Grundauswahl für eine ganze Reihe von Berichte, Formularen, weiteren Abfragen, usw. D.h. diese Abfrage ist ein zentraler Knotenpunkt für fast alles andere aussen herum. Hier würde ich äußerst ungern diese Stringkopiererei bei jedem Formular und Bericht hinterlegen.
Gruß
Thomas
PS: Aber schreib mir bitte trotzdem einmal, wie genau Du dir das vorgestellt hättest. Evtl. bleibt mir ja nichts anderes übrig.
Hallo Thomas,
beschreib bitte dein Problem genauer, sonst kann - und will - dir keiner helfen.
Willst du eine gespeicherte Abfrage modifizieren?
Gruss
Quaser
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo,
also so ganz kann ich Dich auch nicht verstehen, aber es muss doch so sein dass irgendwann jmd. einen Bericht haben möchte, also drückt er auf’s Knöpfchen… Damit das ganze übersichtlich wird kannst Du ja die SQL verändernen ‚Subs‘ in einem Modul speichern, beim Click-Ereigniss greifst Du dann auf die als ‚Public‘ definierten Routinen zu. Diese sollten dann auch den Bericht aufrufen, dann sitzt die ganze Logik in dem Modul und die Buttons haben nur eine auswählende
Funktion.
Gruß
Stefan
Hallo Stefan,
ich versuche es einmal ganz einfach zu erklären…
Ich habe da eine ziemlich große ausführliche Datenbank im System. Auf diese greiffe ich über externe Datenquellen zu. Da ich nun für alle weiteren Operationen nicht alle Daten in dem Ausmaß und in der Zusammensetzung brauchen kann, habe ich als aller erstes eine Abfrage dazwischengeschaltet (diese existiert, hat aber momentan fest eingestellte Werte), welche dann für alles Weitere mehr oder weniger als Pseudo-Tabelle als Datenquelle zur Verfügung steht.
D.h. meine Abfrage ist das erste Glied bei allen weiteren Operationen. Diese Abfrage benutzen dann alle Berichte, Formulare und Abfragen (evt. über eine oder mehrere weitere zwischengeschaltete Abfrage(n)) als Datenquelle.
Eine Einzige Ausnahme hierzu bildet nur Ein Formular, das alle Daten anzeigt, bei dem man dann über einen formularbasierten Filter die Daten auswählen kann. Den SQL-String des Filters habe ich bereits in eine Variable ausgelesen. Nun stellt sich noch die Frage, wie ich beim Aufruf der Eingagsabfrage diese dazu bringen kann, als SQL-Kommando diesen String zu nehmen.
Ich hoffe, das hilft als Erklärung ein wenig weiter.
Gruß
Thomas
Hallo Thomas,
beschreib bitte dein Problem genauer, sonst kann - und will -
dir keiner helfen.
Willst du eine gespeicherte Abfrage modifizieren?Gruss
Quaser
Hallo Quaser,
ja, genau. Ich will eine existierende Abfrage modifizieren, allerdings automatisch immer dann, wenn diese aufgerufen wird, sei es durch einen direkten Aufruf, oder aber, dadurch, daß sie als Datenquelle für irgendetwas anderes angegeben ist.
Gruß
Thomas
Den SQL-String des Filters
habe ich bereits in eine Variable ausgelesen. Nun stellt sich
noch die Frage, wie ich beim Aufruf der Eingagsabfrage diese
dazu bringen kann, als SQL-Kommando diesen String zu nehmen.Ich hoffe, das hilft als Erklärung ein wenig weiter.
Ab da an (dem Zuweisen des SQL-Strings) machst Du dann folgendes:
Dim meineAbfrage as QueryDef ' vorher irgendwo im Deklarationsbereich
Set meineAbfrage=CurrentDb.QueryDefs("meineAbfrageFuerDenBericht")
meineAbfrage.SQL=meinSqlString
Und das war’s schon.
Oder Du erzeugst Dir eine Neue Abfrage mit CreateQueryDef und der Angabe des SQL-Strings. Wenn Du eine bestehende Abfrage vorher löschst, kannst Du auch hier immer wieder den gleichen Namen verwenden.
Gruß, Manfred
1 Like
Normalerweise gibt es wenig Grund, jedes Mal die Abfrage zu ändern, wenn sich Filterkriterien ändern.
Die Filterkriterien kann man der Abfrage ja jeweils neu beistellen, z.B. beim OpenForm, OpenReport usw.
Schau dir dazu vielleicht mal die Beispieldatenbank „Suchen/SQL dynamisch erstellen“ im DBWiki an.
Gruß aus dem Norden
Reinhard Kraasch
(http://www.dbwiki.de - das Datenbank-Wiki)
Hallo Reinhard,
die Idee hatte ich auch schon, aber leider klappt das bei mir nicht ganz. In der von Dir besprochenen Beispieldatenbank wird der SQL-String als Filter für das Anzeigeformular verwendet. Ich aber erstelle einen SQL-String, ohne zu diesem Zeitpunkt zu wissen, was mit diesen Daten dann imm Anschluß weiter passiert. D.h. ich rufe, bei Bedarf einer Datensatzeinschränkung, mein Auswahlformular auf. Die hier getroffene Auswahl soll dann für alle weiteren Funktionen bis zum erneuten Aufruf der Auswahl gelten. Dabei ist aber nicht sichergestellt, daß in allen dann verwendeten Formularen dann auch wieder alle Felder in der vorgeschalteten Abfrage durchgeschleift werden. Ich möchte aber auch nicht mehr Felder und Datensätze als nötig durch die Abfragen durchschleußen, da dies die Laufzeit wesentlich beeinflußt. Ich müßte also schon diesen SQL-String irgendwie in die erste Abfrage einschleußen, die dann wiederum als Datenquelle für alles weitere dient.
Gruß
Thomas
Na ja - auch das wird ja in dem Beispiel gezeigt - an Hand der Exportabfrage. Da wird dann halt jedes Mal die SQL-Eigenschaft der Abfrage umgesetzt. Das setzt natürlich eine Aufteilung der Datenbank und ein lokales Frontend voraus.
Gruß aus dem Norden
Reinhard Kraasch
(http://www.dbwiki.de - das Datenbank-Wiki)
Hallo Reinhard,
ich denke zwar, daß ich jetzt die Stelle gefunden, habe, die du meinst, aber so ganz verstehen tue ich das, was dahintersteht nicht. Ich denke einmal, Du meinst bei der ausführlichen Auswahl die Variante 2 (Recordsource eines Berichtes Ändern).
Ein kleines Problem habe ich aber dabei, wahrscheinlich. Der selektierte Datensatzbereich kann schnell einmal mehrere 10000 Datensätze mit ca. 200 Feldern enthalten. Ich weiß nicht, ob das dann noch geht.
Gruß
Thomas
10000 Datensätze sind eher ein Witz - 200 Spalten können schon eher etwas problematisch werden.
Wenns effizient und flexibel sein soll, sammle halt nur jeweils die Primärschlüssel der Tabelle in einer Zwischentabelle und joine diese auf die Originaldaten zurück…
Gruß aus dem Norden
Reinhard Kraasch
(http://www.dbwiki.de - das Datenbank-Wiki)
1 Like
Hallo Manfred,
nachdem ich lange an Deinem Vorschlag hin und her Probiert habe, dann aber immer an dem _ Dim meineAbfrage As QueryDef _ gescheitert bin, da Access anscheined dieses _ QueryDef _ nicht kennt, bin ich trotzdem indirekt auf eine ziemlich passable Lösung gekommen. 
CurrentDb.QueryDefs("Name der Abfrage").SQL = SQL-String
So einfach wäre es, wenn man immer alle Befehle kennen würde aber in der Summe mit den vielen Antworten habe ich dann letztendlich nach wochenlangem Probieren und Suchen doch ein Ergebnis erreicht. Die Idden von Reinhard schauen auch noch ganz interessant aus, die werde ich mir als Alternative nun auch noch genauer zu Gemüte führen. Vielleicht kommt ja noch etwas besseres heraus.
Gruß
Thomas