Parameter an Parameter-Abfrage übergeben

[Michael König]

Hallo Newsgroup,

mal wieder ein (für mich großes) Problem: ich habe mehrere verschiedene
Parameter-Abfragen als Datenlieferanten für Berichte. Rufe ich so einen
Bericht aus dem Datenbankfenster auf, werde ich nach dem Parameter
gefragt und der Bericht wird korrekt erstellt.
Nun möchte ich diese vielen Berichte aus einem Formular aufrufen, bei
Bedarf den Parameter per Textfeld in diesem Formular eingeben und dann
den Bericht zusammen mit dem eingegebenen Wert erstellen lassen.
Wenn möglich möchte ich dazu die vorhandenen Parameter-Abfragen
weiterhin benutzen, nur an diese den bereits ins Textfeld eingegebenen
Wert als Parameter übergeben.
Geht so etwas (Access 2000, Win'XP SP2, DAO 3.6)?

Gruß
Michael

[Gunter Avenius]

Hallo Michael,

Post by Michael König
mal wieder ein (für mich großes) Problem: ich habe mehrere
verschiedene Parameter-Abfragen als Datenlieferanten für Berichte.
Rufe ich so einen Bericht aus dem Datenbankfenster auf, werde ich
nach dem Parameter gefragt und der Bericht wird korrekt erstellt.
Nun möchte ich diese vielen Berichte aus einem Formular aufrufen,
bei Bedarf den Parameter per Textfeld in diesem Formular eingeben
und dann den Bericht zusammen mit dem eingegebenen Wert erstellen
lassen.
Wenn möglich möchte ich dazu die vorhandenen Parameter-Abfragen
weiterhin benutzen, nur an diese den bereits ins Textfeld
eingegebenen Wert als Parameter übergeben.
Geht so etwas (Access 2000, Win'XP SP2, DAO 3.6)?

Als Kriterium:

=Forms!DeinFormular!DeinFeld

[Michael König]

Hallo Gunter,

Post by Gunter Avenius
=Forms!DeinFormular!DeinFeld

danke, das kenne ich auch. Nur wenn ich dies als Kriterium eingebe, kann
ich den Bericht nur noch per Formular und nicht mehr (zu Testzwecken)
aus dem Datenbankfenster erstellen lassen.

CU

[Gunter Avenius]

Hallo Michael,

Post by Michael König
danke, das kenne ich auch. Nur wenn ich dies als Kriterium eingebe,
kann ich den Bericht nur noch per Formular und nicht mehr (zu
Testzwecken) aus dem Datenbankfenster erstellen lassen.

? wenn es damit ein problem geben sollte trägst Du zum Testzweck halt
feste Werte ein.

[Karl Donaubauer]

Post by Michael König

Post by Gunter Avenius
=Forms!DeinFormular!DeinFeld

danke, das kenne ich auch. Nur wenn ich dies als Kriterium eingebe, kann
ich den Bericht nur noch per Formular und nicht mehr (zu Testzwecken)
aus dem Datenbankfenster erstellen lassen.

Warum nicht?
Du wirst doch dann bloß per Parameterfenster nach dem Wert gefragt,
so wie bei jedem anderen Parameter, den Access nicht von selber
mit einem Wert belegen kann.

[Klaus Oberdalhoff]

Hi,

Post by Michael König
mal wieder ein (für mich großes) Problem: ich habe mehrere
verschiedene Parameter-Abfragen als Datenlieferanten für Berichte.

Punkt 6.16 der Access-FAQ www.donkarl.com kennst du ?
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Michael König]

Hallo Klaus,

Post by Klaus Oberdalhoff
Hi,

Post by Michael König
mal wieder ein (für mich großes) Problem: ich habe mehrere
verschiedene Parameter-Abfragen als Datenlieferanten für Berichte.

Punkt 6.16 der Access-FAQ www.donkarl.com kennst du ?

danke ja, kenne ich, hab' ich verstanden ;-)
Nur weiß ich nicht, wie ich anschließend das so gebildete Recordset dem
anschließend zu öffnenden Bericht als Recordsource übergeben kann.

CU

[Klaus Oberdalhoff]

Hi,

Post by Michael König
danke ja, kenne ich, hab' ich verstanden ;-)
Nur weiß ich nicht, wie ich anschließend das so gebildete Recordset
dem anschließend zu öffnenden Bericht als Recordsource übergeben kann.

im schlimmsten Fall indem du den Bericht OHNE Recordsource abspeicherst, ihn
öffnest, und nach dem öffnen ihm einmalig den Recordsource unterjubelst
(aber Achtung, Beim Öffnen kann man zwar EINMALIG einem Bericht eine neue
RecordSource unterhjubeln, aber beim zweiten Versuch krachts, also Fehler
abfangen oder On Error Resume Next (speziell wenn Unterbericht, der
automatisch mehrmals geöffnet wird).

oder indem du das RecordSet als Query abspeicherst oder oder oder ..

Ich arbeite meistens ohne diese komischen Parameterabfragen sondern habe mir
in Access angewöhnt, den SQL-Code "on the fly" zusammenzuschreibseln und
diese Abfrage dann als RecordSource, query, oder RowSource oder was auch
immer zu verwenden...

Um z.B. in DAO eine Abfrage zu erzeugen, habe ich mir eine kleine Procedure
geschrieben, die das für mich erledigt:

Function CreateQuery(strSQL As String, Queryname As String) As Boolean

Dim dbs As Database
Dim qdf As QueryDef

On Error GoTo CreateQuery_Error

Set dbs = CurrentDb
If ObjectExists("Query", Queryname) Then
DoCmd.DeleteObject acQuery, Queryname
End If
Set qdf = dbs.CreateQueryDef(Queryname, strSQL)

DoEvents

CreateQuery = True
On Error GoTo 0
Exit Function

CreateQuery_Error:

' MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure
CreateQuery of Modul mdlSonstiges5"
CreateQuery = False

End Function

Da ich ja den Querynamen kenne, kann ich so dem gleichen Report unter dem
gleichen Namen verschiedene Queries unterjubeln. Ist, wenn man das mal
gewöhnt ist, echt einfach und ist auch von der Ausführungsgeschwindigkeit
(Erzeugen der Query) einfach supii.

Manchmal verwende ich auch das Modul mdlPrivProperty (aus der KnowHow siehe
Signatur) und speichere die Recordsource als Parameter ab, den ich dann beim
Open des Reports lese und zuweise.

Wie gesagt, da ist Access EXTREM flexibel, und es führen echt tausende Wege
nach Rom ...
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Michael König]

Hallo Klaus,

Post by Klaus Oberdalhoff
im schlimmsten Fall indem du den Bericht OHNE Recordsource abspeicherst,
ihn öffnest, und nach dem öffnen ihm einmalig den Recordsource
unterjubelst (aber Achtung, Beim Öffnen kann man zwar EINMALIG einem
Bericht eine neue RecordSource unterhjubeln, aber beim zweiten Versuch
krachts, also Fehler abfangen oder On Error Resume Next (speziell wenn
Unterbericht, der automatisch mehrmals geöffnet wird).

okay, Warnung verstanden, aber wie "unterjubeln"?
Annahme: ich habe ein qdf-Objekt wie in FAQ 6.16 als Muster, daraus ein
Recordset rs
Jetzt folgt
DoCmd.OpenReport Reportname, OpenMode
kann ich jetzt einfach schreiben:
Reports(Reportname).Recordsource = rs ???

Post by Klaus Oberdalhoff
Function CreateQuery(strSQL As String, Queryname As String) As Boolean

das lasse ich mir mal in aller Ruhe durch den Kopf gehen, trotzdem zum
Verständnis (=Lernen): wie ist das mit der Recordsource?

Danke für Deine Mühe

Gruß
Michael

[Thomas Möller]

Hallo Michael,

Post by Michael König

Post by Klaus Oberdalhoff
im schlimmsten Fall indem du den Bericht OHNE Recordsource
abspeicherst, ihn öffnest, und nach dem öffnen ihm einmalig den
Recordsource unterjubelst (aber Achtung, Beim Öffnen kann man zwar
EINMALIG einem Bericht eine neue RecordSource unterhjubeln, aber
beim zweiten Versuch krachts, also Fehler abfangen oder On Error
Resume Next (speziell wenn Unterbericht, der automatisch mehrmals
geöffnet wird).

okay, Warnung verstanden, aber wie "unterjubeln"?
Annahme: ich habe ein qdf-Objekt wie in FAQ 6.16 als Muster, daraus
ein Recordset rs
Jetzt folgt
DoCmd.OpenReport Reportname, OpenMode
Reports(Reportname).Recordsource = rs ???

schau mal auf meiner HP. Unter Access / Tipps und Tricks findet sich ein
Artikel mit dem Namen "Berichte in Access". Im Punkt "Recordset als
Datenquelle" habe ich das Vorgehen beschrieben.

CU

[Klaus Oberdalhoff]

Hi,

Post by Thomas Möller
schau mal auf meiner HP. Unter Access / Tipps und Tricks findet sich
ein Artikel mit dem Namen "Berichte in Access". Im Punkt "Recordset
als Datenquelle" habe ich das Vorgehen beschrieben.

Super Tipp, danke.

Vielleicht solltest du in dem Bericht noch erwähnen (mit Beispiel?) dass man
damit auf einfache Art und Weise Stored Procedures aufrufen kann. Für
"normale" Recordsets macht dieses Vorgehen nämlich wenig Sinn, aber für
Stored Procs ist es einfach unerläßlich?

mfg

Klaus Oberdalhoff

[Thomas Möller]

Hallo Klaus,

Post by Klaus Oberdalhoff

Post by Thomas Möller
schau mal auf meiner HP. Unter Access / Tipps und Tricks findet sich
ein Artikel mit dem Namen "Berichte in Access". Im Punkt "Recordset
als Datenquelle" habe ich das Vorgehen beschrieben.

Super Tipp, danke.
Vielleicht solltest du in dem Bericht noch erwähnen (mit Beispiel?)
dass man damit auf einfache Art und Weise Stored Procedures aufrufen
kann. Für "normale" Recordsets macht dieses Vorgehen nämlich wenig
Sinn, aber für Stored Procs ist es einfach unerläßlich?

um die Daten aus der Stored Procedure zu holen würdest Du dann aber ein
ADO-recordset brauchen - oder? Das Beispiel funktioniert leider nur mit
DAO-Recordsets.

CU

[Klaus Oberdalhoff]

Hi,

Post by Thomas Möller
um die Daten aus der Stored Procedure zu holen würdest Du dann aber
ein ADO-recordset brauchen - oder? Das Beispiel funktioniert leider
nur mit DAO-Recordsets.

Diese Aussage ist so nicht korrekt. Auch mit DAO.Recordsets sind ODBC
Direktabfragen durchaus möglich, wenn auch die Möglichkeiten wohl mit ADO,
OLEDB bzw. SQLDB und was es da alles neueres gibt (MS erfindet ja mindestens
einmal jährlich seine Datenzugriffsmethode neu) erweitert wurden.

Nur als Randbemerkung: Da ich bisher nicht bereit war, dieses MS "Bäumchen
wechsel dich" Spielchen mitzuspielen, bin ich bisher <von manchen belächelt>
auf DAO - und MDBs "sitzengeblieben" und werde erst wieder (im Zusammenhang
mit VS 2005) mit ADO.NET 2.0 neu in dieses Karusell einsteigen (ohne jedoch
dabei das Gefühl zu haben, bisher viel versäumt zu haben <g>). In der Praxis
kann man ja auf eine "View" zugreifen wie auf eine Tabelle, und das hat mir
in aller Regel bisher vollkommen ausgereicht. Irgendwie ist es schon lustig;
in der neuesten (Beta)-Version von Access wird von MS wieder empfohlen, man
möge doch DAO verwenden, da zwischenzeitlich die Weiterentwicklung von ADO
(nicht zu verwechseln mit ADO.NET 2.0) gestoppt/eingefrohren wurde, und man
DAO benötigt, um die neuen Features von Access zu nutzen. Ja ja, so ändern
sich die Zeiten <g>

Ich habe - um bei dem Kuddelmuddel nix falsches zu sagen (und um mich nicht
zu blamieren <g>) - einfach mal wieder in älteren Büchern zu DAO und
PassThrough und StoredProcedures gestöbert. Da wird man fündig.
<VBA-Programmierung mit Access 97 / Albrecht - Nicol / Addison-Wesley und im
(zwischenzeitlich total zerfledderten und zerlesenen) MS Access Developers
Guide TO SQL Server / Chipman - Baron / Samspublishing>

Also - lange Rede kurzer Sinn - diese Bücher beschreiben durchaus Mittel und
Wege, und Beispiele um mittels DAO.Recordsets auf Stored Procedures
zuzugreifen. Dazu gibt es ja auch schliesslich den Parameter
dbSQLPassThrough im DAO.OpenRecordset ...

Nein, Beispiel habe ich leider keines, ich habe es i der jüngeren
Vergangenheit nur einmal benötigt, und das war, um einen Befehl an den
SQL-Server zu senden, damit ich eine Tabellenspalte, die im SQL Server als
Autowert beschrieben ist, überschreiben konnte und ich so die "alten"
Autowert-Werte von Access manuell ex/importieren konnte.
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Thomas Möller]

Hallo Klaus,

Post by Klaus Oberdalhoff
Nur als Randbemerkung: Da ich bisher nicht bereit war, dieses MS
"Bäumchen wechsel dich" Spielchen mitzuspielen, bin ich bisher <von
manchen belächelt> auf DAO - und MDBs "sitzengeblieben"

Da bist Du wohl nicht der einzige. ;-)

Bei uns im Geschäft kommt DB/2 als BackEnd zum Einsatz. Als FrontEnd
verwenden wir Access. Der Zugriff auf die Daten erfolgt fast ausschliesslich
über PT-Abfragen. Diese lassen sich gut als Grundlage für ein Recorset
verwenden.

Post by Klaus Oberdalhoff
Also - lange Rede kurzer Sinn - diese Bücher beschreiben durchaus
Mittel und Wege, und Beispiele um mittels DAO.Recordsets auf Stored
Procedures zuzugreifen. Dazu gibt es ja auch schliesslich den
Parameter dbSQLPassThrough im DAO.OpenRecordset ...

Die Möglichkeit auf DB/2 SP's und UDF's zu erstellen steht technisch erst
seit wenigen Wochen zur Verfügung. Aus diesem Grund fehlt mir momentan noch
ein konkretes Beispiel.

Wenn die erste SP läuft werde ich dann das Beispiel auf meiner HP erweitern.

CU

[Klaus Oberdalhoff]

Hi,

Post by Thomas Möller
um die Daten aus der Stored Procedure zu holen würdest Du dann aber
ein ADO-recordset brauchen - oder? Das Beispiel funktioniert leider
nur mit DAO-Recordsets.

später Nachtrag.

aus aktuellem Anlass mal in der Hilfe gesucht und bin auch für ADO fündig
geworden. Soweit ich weiss geht das allerdings erst ab Access XP bzw. 2003
...

Aus der Hilfe zu Recordset:

Das folgende Beispiel öffnet ein Formular, öffnet ein Recordset und bindet
dann das Formular an das Recordset, indem die Recordset-Eigenschaft des
Formulars auf das neu erstellte Recordset-Objekt festgelegt wird.
Global rstSuppliers As ADODB.Recordset
Sub MakeRW()
DoCmd.OpenForm "Suppliers"
Set rstSuppliers = New ADODB.Recordset
rstSuppliers.CursorLocation = adUseClient
rstSuppliers.Open "Select * From Suppliers", _
CurrentProject.Connection, adOpenKeyset, adLockOptimistic
Set Forms("Suppliers").Recordset = rstSuppliers
End Sub
Die Recordset-Eigenschaft wird für folgende Aufgaben verwendet:
Binden mehrerer Formulare an eine gemeinsame Datengruppe. Dadurch können
mehrere Formulare synchronisiert werden. Beispiel:

Set Me.Recordset = Forms!Form1.Recordset

etc etc pp
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Klaus Oberdalhoff]

Hi,

Post by Michael König
das lasse ich mir mal in aller Ruhe durch den Kopf gehen, trotzdem zum
Verständnis (=Lernen): wie ist das mit der Recordsource?

ganz einfach: Als Row- oder RecordSource entweder eine Tabelle, eine Query,
ein Select-Statement oder auch eine Funktion mit =DeineFunction() oder (hier
in einer Rowsource) sowas wie "=Wenn([werte]>=7 Und
[werte]<=10;"²²²²²²²²²")" verwenden, mit einem Recordset / Querydef kannst
du an dieser Stelle eher wenig anfangen, daher ja meine Tipps. (Bei ADPs ist
es wohl etwas anders, aber da fragst du besser andere, die sich besser damit
auskennen ...)

Anstelle einer Query mit Parametern verwende ich bei Forms und Reports Die
Abfrage und setze beim OpenForm oder Report auf die Whereklausel ohne Where.

Docmd.OpenReport "DeinReport",,"Whereklausel ohne Where"

(funktioniert zumindest seit Acc97) nur beim Report gab es in Acc97 noch
keine Möglichkeit Öffungsargumente mitzugeben.
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Michael Zimmermann]

Hallo!

Post by Klaus Oberdalhoff
Ich arbeite meistens ohne diese komischen
Parameterabfragen sondern habe mir in Access angewöhnt,
den SQL-Code "on the fly" zusammenzuschreibseln und diese
Abfrage dann als RecordSource, query, oder RowSource oder
was auch immer zu verwenden...

Im ein oder anderen Einzelfall ist das eine elegante
und praktische Lösung, als /allgemeines Prinzip/ der
DB-Programmierung aber eher desaströs.

Bei diesem Vorgehen werden die internen Mechanismen, die
Access zur Abfrageoptimierung einsetzt, insbesondere die
Statistiken für den optimalen Ausführungsplan, völlig aus
dem Tritt gebracht.

Für Basisabragen auf größere Datenbestände der
Hauptanwendungsobjekte ist eine gespeicherte Abfrage
ganz klar vorzuziehen.

Gruß aus Mainz
Michael

[Klaus Oberdalhoff]

Hi,

Post by Michael Zimmermann
Für Basisabragen auf größere Datenbestände der
Hauptanwendungsobjekte ist eine gespeicherte Abfrage
ganz klar vorzuziehen.

vollkommen d'accord.

Ich SPEICHERE die Abfragen ja meist vorher mit der oa Funktion ab und rufe
dann den Bericht / das Formular mit der gespeicherten Abfrage !!! auf...
--
mfg

Klaus Oberdalhoff ***@gmx.de

Ich beantworte keine NG-Fragen und -Nachfragen per Mail!
Newbie-Info: http://www.doerbandt.de/Access/Newbie.htm
KnowHow-mdb und andere Beispiele: http://www.freeaccess.de
Sofern Access 200x bitte beachten:
http://www.freeaccess.de/MS-Access-Artikel.asp?ID=99

[Michael Zimmermann]

Hallo!

Post by Klaus Oberdalhoff

Post by Michael Zimmermann
Für Basisabragen auf größere Datenbestände der
Hauptanwendungsobjekte ist eine gespeicherte Abfrage
ganz klar vorzuziehen.

vollkommen d'accord.
Ich SPEICHERE die Abfragen ja meist vorher mit der oa
Funktion ab und rufe dann den Bericht / das Formular mit
der gespeicherten Abfrage !!! auf...

Du mußt aber diese Abfrage auch gespeichert lassen und
immer wieder benutzen. Sonst ist die Statistik ja dauerhaft
jungfräulich unwissend.

Gruß aus Mainz
Michael