Wert für Parameterabfrage per Programmcode übergeben
Albert Weinert
Hallo zusammen,
ich möchte gerne bei einer Parameterabfrage den Wert per Programmcode
einstellen können und ihn nicht manuell eingeben (lassen) müssen.
Es sollte so Funktionieren das man die Abfragen von Access aus
anzeigen lassen kann (wie DoCmd.OpenQuery) und natürlich das diese
Abfrage dann auch in Berichten anzuwenden.
Ich möchte nicht so gerne den Umweg über ein Formular gehen wo der
Wert abgelegt wird und auf das Formularfeld anstelle des Parameters
zugegriffen wird.
Wäre gut wenn es da etwas geben würde, wer weiss es?
Freundliche Grüße
Albert
Klaus Oberdalhoff
Hi,
sollte gehen. Aus einer anderen News:
>>>>
Die Abfrage muß seperat existieren.
etwa so:
set db=db.current()
set abfrage=db.openquery("Bericht")
abfrage.parameter=[forms]![irgendeine Form]![wert]
tab=abfrage.openrecordset()
<<<<<
Schau auch mal in der Hilfe unter Parameterabfragen. Du solltest fündig
werden <g>
mfg
Klaus
PS:Tips und Tricks zu ACCESS 97 (**neu** KnowHow-MDB **neu** Ver 1.4:
30.4.98) unter
http://members.aol.com/HLanger51/index.html oder
http://www.freeaccess.de
PPS: Bitte XXNOSPAMXX aus meiner E-mail-Adresse entfernen
Albert Weinert schrieb in Nachricht
<356347c5...@msnews.microsoft.com>...
Albert Weinert
>Hi,
>
>sollte gehen. Aus einer anderen News:
>
>>>>>
>
>Die Abfrage muß seperat existieren.
>etwa so:
>set db=db.current()
>set abfrage=db.openquery("Bericht")
>abfrage.parameter=[forms]![irgendeine Form]![wert]
>tab=abfrage.openrecordset()
Also, ich weiss nicht was das ist, aber Access ist es definitiv nicht
...
Ich möchte auch kein Recordset, da ich diesen Recordset ja
nicht in
>
><<<<<
>
>Schau auch mal in der Hilfe unter Parameterabfragen. Du solltest fündig
>werden <g>
Hätte ich da etwas passendes gefunden würde ich hier nicht fragen (im
Gegensatz zu vielen andere). Dort gibt es nur Infos über
Parameterabfragen bei denen ein eigenes Recordset erstellt werde das,
klappt ja auch wunder bar (so wie hier, ein Beispiel, entspricht nicht
den richtigen Daten).
Sub TestDingens()
Dim db As Database
Dim qd As QueryDef
Dim rs As Recordset
Set db = CurrentDb()
Set qd = db.QueryDefs("TestAbfrage")
qd.Parameters("KName") = "Albert"
Set rs = qd.OpenRecordset()
If rs.RecordCount > 0 Then
MsgBox qd.SQL
End If
rs.Close
Set rs = Nothing
Set qd = Nothing
Set db = Nothing
End Sub
Aber wie bekommt ich nun diesen Recordset, oder den QueryDef an den
Bericht übergeben? Setze ich "TestAbfrage" als Datenquelle ein, und
öffne den Bericht an der Stelle wo ich den Recordset erzeuge
(DoCmd.OpenReport "TestBericht", acViewPreview), werde ich direkt
nach KName gefragt.
Noch irgendwelche Ideen? Ich habe die Vermutung das es evtl.
gar nicht geht, dann bleibt mir nur der Umweg den Wert in ein Formular
Feld zu schreiben und dann in der Abfrage darauf zu verweisen, was
ich eigentlich nicht machen wollte, da ich es nicht als sonderlich
Sauber erachte.
Freundliche Grüße
Albert
Klaus Oberdalhoff
Hi,
uuuuppssss, sorry, Frage nicht richtig gelesen :-((
Hoffe, du verzeihst mir nochmal <g>
Ich weiß die Antwort leider auch nicht, sorry.
Unten eine Antwort (der Attag Group) aus FAQ´s die ich gefunden habe.
Vielleicht hilft die weiter ... (Ich hab´ sie noch nicht ausprobiert).
Vieleicht schaust du auch mal in folgenden 2 Beispiel-MDB´s von MS, ob da
was dabei ist ? Ich hab´ mir da schon manchen Tip geholt ...
ftp://ftp.microsoft.com/softlib/mslfiles/QRYSMP97.EXE (Query Samples)
ftp://ftp.microsoft.com/softlib/mslfiles/RPTSMP97.EXE (Report Samples)
------------------------
How to Send Parameters to Reports only Using Code (Not using Query By Form)
'Attac Group
Access developers sooner or later run into a situation where they need to
generate reports which are filtered or use parameters, but where all the
parameters need to be set via code, rather than having them pulled from a
form using query by form.
Most developer's know how to set parameters for opening a recordset, using
the parameters property of the DAO QueryDef object. There are two rather
simple ways to do set parameters when working with a Report object rather
than with the standard record set:
For the underlying query of the report add no parameters to the query. Then
each time you print or preview the report, set an SQL where clause for the
report when you use the OpenReport method.
Using method number 1 may get cumbersome and error prone having to create
the SQL string each time the report is called in code. In addition because
you can't always use the OpenReport method to print a report (especially if
you want multiple copies where you need to use the Print Action etc,) a
second option is to create and set the values of a parameter array which is
called by your report's query. Here's how to do it:
Create a new general module, and on the declarations page dimension a
variant array. (We'll use a 10 element array but it can be any size, the
smaller the better to efficiently use memory.) Use a variant array because
you need it to hold any type of data.
Dim arrParameters(10)
Create a new Sub Procedure which allows you to set the values of the array
such as:
Public Sub SetParam(ByVal InputVal, ByVal ParamID)
arrParameter(ParamID) = InputVal
End Sub
Where the InputVal is the value of the parameter, and ID is the parameter
number you will be setting.
Create a similar Function to retreive the value of the parameter from the
array:
Public Function GetParam(ByVal ParamID)
GetParam = arrParameter(ParamID)
End Function
Then in your query for the report where you would normally set a parameter
in the criteria section simply place a call to the function to get a
parameter as in:
=GetParam(X)
Where X = 1 or 2 or 3 and so on for the number of parameters for the query.
Then in your VB code, prior to opening the report, simply call the SetParam
subprocedure for each parameter of the report with the values of the
parameters you want to the report to use, as in:
Public Sub PrintRegistrationsRpt(BeginDate, EndDate)
Call SetParam(BeginDate, 1)
Call SetParam(EndDate, 2)
DoCmd.OpenReport "ClassRegistratons", A_Normal
End Sub
---------------------
mfg
Klaus
PS:Tips und Tricks zu ACCESS 97 (**neu** KnowHow-MDB **neu** Ver 1.4:
30.4.98) unter
http://members.aol.com/HLanger51/index.html oder
http://www.freeaccess.de
PPS: Bitte XXNOSPAMXX aus meiner E-mail-Adresse entfernen
Albert Weinert schrieb in Nachricht
<356405dd...@msnews.microsoft.com>...
Heinz Wiedow
Hallo Albert,
es gibt da eigentlich nur zwei Möglichkeiten:
1.) Du kannst eine Funktion erstellen die Du dann in einer Parameterabfrage
aufrufst.
2.) Du erstellst ein Querry Def
Auf jeden Fall, muß die Abfrage in der Datenbank gespeichert werden. mit
einem SQL Statement im Code funktioniert es nicht.
Solltest Du nicht weiterkommen, maile ich Dir gern ein Beispiel
--
--
Gruß
Heinz Wiedow
Harald Langer
Hi Heinz,
ich hab' die Frage irgendwie nicht richtig verstanden.
Irgendwann müssen ja irgendwie mal die Parameter übergeben werden.
Auf jeden Fall muß er auf einen irgendwann mal irgendwo hinterlegten Wert
zurückgreifen. Oder???
Ob nun mit Funktion oder globaler Variable....
Wenn er sich auf Basis einer Abfrage mit wechselnden Kriterien einen
Bericht ausgeben lassen will, dann muß die Abfrage aber nicht gespeichert
sein. Er kann sich die Datenherkunft zur Laufzeit zusammenstellen. Null
problemo.
Aber vielleicht hab' ich ja auch wirklich nicht verstanden. Dann -
'tschuldigung!
Gruß
Harald
--
Freeware zu Access97: http://members.aol.com/HLanger51/
Heinz Wiedow <heinz....@mail.niederrhein.de> schrieb im Beitrag
Albert Weinert
>ich hab' die Frage irgendwie nicht richtig verstanden.
>Irgendwann müssen ja irgendwie mal die Parameter übergeben werden.
>Auf jeden Fall muß er auf einen irgendwann mal irgendwo hinterlegten Wert
>zurückgreifen. Oder???
>Ob nun mit Funktion oder globaler Variable....
>
>Wenn er sich auf Basis einer Abfrage mit wechselnden Kriterien einen
>Bericht ausgeben lassen will, dann muß die Abfrage aber nicht gespeichert
>sein. Er kann sich die Datenherkunft zur Laufzeit zusammenstellen. Null
>problemo.
Klar ist das eigentlich Null Problem. Der Fall ist aber etwas
komplizierter.
1) Ich habe 12 Tabellen mit Umsätzen von Kunden (ca. 2 bis 3 Mio
Datensätze je Tabelle, ich weiss Access ist dafür nicht sonderlich
geeignet, funktioniert aber trotzdem erstaunlich fix).
2) Von jeder dieser Tabelle wird eine Abfrage erstellt die die
Umsätze nach den Geschäftsfeldern aufsummiert (und noch ein
paar andere Kleinigkeiten, wie Kundenzusammenfassen)
3) Über alle 12 Abfragen wird mit ein UNION Abfrage der Jahresumsatz
der Kunden ermittelt (nach Monaten aufgeteilt), auf diese basiert dann
der Bericht und eine Kreuztabelle. Dies immer für einen bestimmten
Kunden.
Damit es in einer vernünftigen Zeit abläuft wird nun via eines
Parameters bei den Abfragen (2) schon auf einen bestimmten
Kunden mit WHERE reduziert. Interessant ist das über die Abfragen in
(3) der Parameter einmal abgefragt wird und dann an alle Abfragen bei
(2) weitergereicht.
Auf Grund der komplexzität der ganzen ist es relativ schwierig diese
Abfrage zur Laufzeit zu generieren und im Bericht einzusetzen.
>Aber vielleicht hab' ich ja auch wirklich nicht verstanden. Dann -
>'tschuldigung!
Jein! Es gibt bei SQL die Möglichkeit einer Parameter Abfrage,
PARAMETERS KName TEXT;
SELECT * FROM Namen WHERE Vorname = KName;
Rufe ich nun die Abfrage auf werde ich nach KName gefragt. Den
Wert von KName kann ich auch via VBA im QueryDef setzen und
daraufhin einen Recordset öffnen, aber den QueryDef kann ich
nicht einem Bericht übergeben.
Aber ich werde es nun mit einer globale Parameterfunktion machen (wie
von Klaus zitiert), das scheint mir die sauberste Lösung zu sein.
Freundliche Grüße
Albert
Albert Weinert
>1.) Du kannst eine Funktion erstellen die Du dann in einer Parameterabfrage
>aufrufst.
So werde ich es machen.
>2.) Du erstellst ein Querry Def
Geht nicht weil ... sie andere Nachrichten von mir.
Freundliche Grüße
Albert
Albert Weinert
>uuuuppssss, sorry, Frage nicht richtig gelesen :-((
Macht ja nichts.
>Hoffe, du verzeihst mir nochmal <g>
Hmm, ich weiss nicht ob ich Dir diesen Schnitzer durchgehen lassen
kann ... naja, gut einmal noch :)
>Unten eine Antwort (der Attag Group) aus FAQ´s die ich gefunden habe.
>Vielleicht hilft die weiter ... (Ich hab´ sie noch nicht ausprobiert).
Ja, das ist eine gute Idee, so werde ich es probieren, allerdings
werde ich kein Array benutzen, sondern ein Collection Object,
aber die Idee ist gut, besser wie der Weg über ein Formular.
Freundliche Grüße
Albert