Stored Procedure prüfen
Lothar Geyer
ein Modul mit einer speziellen Funktion vorhanden ist?
Und wie bei SQLserver / Express?
Lothar Geyer
Helmut Meukel
news:80oisn...@mid.individual.net...
Lothar,
deine Fragestellung ist unklar. Was meinst du mit "Modul mit einer
speziellen Funktion"? Einen VBA-Modul mit einer in Access-VBA
programmierten Function? Da kann ich dir nicht helfen.
Wenn du aber das Access-Äquivalent einer Stored Procedure
meinst, also eine Abfrage (Query), dann könntest du z.B. folgendes
tun.
- mit DAO:
entweder
Dim db As Database, qry As QueryDef
Set db = DBEngine.OpenDatabase("MyDB_NamePfad")
for each qry in db.querydefs
'ist die gesuchte Abfrage vorhanden und was dann?
...
next
oder direkt:
Dim db As Database, qry As QueryDef
Const sql = "SELECT DatumZeit, ErhitzerDaten.SchrittNr, Protokolliert,
Meldetext FROM ErhitzerDaten LEFT JOIN ErhitzerMeldetexte ON
ErhitzerDaten.SchrittNr = ErhitzerMeldetexte.SchrittNr WHERE (Protokolliert =
False) ORDER BY DatumZeit;"
Set db = DBEngine.OpenDatabase("MyDB_NamePfad")
Set qry = dbE.QueryDefs("tl_ErhitzerNichtProtokolliert")
On Error GoTo 0
If qry Is Nothing Then
Set qry = db.CreateQueryDef("tl_ErhitzerNichtProtokolliert", sql)
Endif
Im zweiten Beispiel steht der Text der SQL-Abfrage im Programm,
das Programm versucht aber zuerst die in der Access-Mdb gespeicherte
Abfrage zu starten, nur wenn sie nicht da ist wird sie neu angelegt.
Eine gespeichrte Abfrage ist deutlich schneller in der Ausführung,
deshalb diese Konstruktion. Nebeneffekt: wenn jemand die gespeicherte
Abfrage aus der DB versehentlich löscht, legt sie das Programm erneut
an.
Ich verwende während der Programmentwicklung eine DB mit Testdaten
und erzeuge dort die Abfragen direkt in Access. Liefert sie die
gewünschten Ergebnisse, so kopiere ich den SQL-String ins Programm.
Wenn das Programm dann in den Echtbetrieb geht, brauche ich die
Abfragen nicht aus der Test-DB in die Echt-DB zu kopieren, das
Programm legt sie beim ersten Lauf selbst an.
mfg.
Helmut.
Helmut Meukel
news:eLjJFURz...@TK2MSFTNGP05.phx.gbl...
> Set qry = dbE.QueryDefs("tl_ErhitzerNichtProtokolliert")
Falls sich jemand ï¿œber den Prï¿œfix des Querynamens wundert, das
Programm heiï¿œt Tanklager und der Prï¿œfix soll andere Benutzer der
Datenbank darauf hinweisen dass dies eine vom Tanklager-Programm
verwendete Abfrage ist die man nicht einfach den eigenen
Bedï¿œrfnissen anpassen darf.
Ich habe in einer der DBs z.B. auch Abfragen die von VBA-Code
in Excel-Datenblï¿œttern verwendet werden fï¿œr Monats- und
Jahresstatistiken. die haben dann die Prï¿œfixe xm_ und xj_
Daneben gibt es Abfragen von 3 verschiedenen Programme mit
entsprechenden Prï¿œfixen. Das hilft den ï¿œberblick zu behalten.
Helmut.
Lothar Geyer
Am 26.03.2010 19:48, schrieb Helmut Meukel:
> "Lothar Geyer" <Lothar...@EDV-Berater-Online.de> schrieb im
> Newsbeitrag news:80oisn...@mid.individual.net...
>> Wie kann mittels VB6-Anwendung ich prüfen, ob in einer
>> Access-Datenbank ein Modul mit einer speziellen Funktion vorhanden ist?
>>
>> Und wie bei SQLserver / Express?
> deine Fragestellung ist unklar. Was meinst du mit "Modul mit einer
> speziellen Funktion"? Einen VBA-Modul mit einer in Access-VBA
> programmierten Function? Da kann ich dir nicht helfen.
Das ist schade. Genau das bräuchte ich. Aber vielleicht hast Du ja eine
Idee.
Es geht um eine Funktion zur Berechnung der Kalenderwoche, damit ich in
einer SQL-Abfrage Wochensummen ermitteln kann. Die mitgelieferte
KW-Berechnung arbeitet ja nicht nach den europäischen Standards bzw. ist
fehlerhaft.
Und nun möchte ich mit einem Upgrade-Programm ein entsprechendes Modul
in die Datenbank einbauen bzw. (für spätere Versionen des Programms)
auch einen Austausch gegen eine neue Version des Moduls vorsehen.
Lothar Geyer
Helmut Meukel
> Hallo Helmut,
>
> Am 26.03.2010 19:48, schrieb Helmut Meukel:
>> "Lothar Geyer" <Lothar...@EDV-Berater-Online.de> schrieb im
>> Newsbeitrag news:80oisn...@mid.individual.net...
>>> Access-Datenbank ein Modul mit einer speziellen Funktion vorhanden ist?
>>>
>>> Und wie bei SQLserver / Express?
>> deine Fragestellung ist unklar. Was meinst du mit "Modul mit einer
>> speziellen Funktion"? Einen VBA-Modul mit einer in Access-VBA
>> programmierten Function? Da kann ich dir nicht helfen.
>
>
> Es geht um eine Funktion zur Berechnung der Kalenderwoche, damit ich in einer
> SQL-Abfrage Wochensummen ermitteln kann. Die mitgelieferte KW-Berechnung
>
> Und nun mï¿œchte ich mit einem Upgrade-Programm ein entsprechendes Modul in die
> Datenbank einbauen bzw. (fï¿œr spï¿œtere Versionen des Programms) auch einen
>
> Lothar Geyer
Hallo Lothar,
wenn ich Dch richtig verstehe, so hast Du Access mit VBA programmiert und
mï¿œchtest jetzt in die Datenbank(en) per VB6 ein Code-Modul mit dieser
KW-Funktion reinschieben?
Wenn das ï¿œberhaupt geht, dann kann ich mir das nur ï¿œber Automatisierung
von Access vorstellen. Ich habe mich bisher nur mit dem Objekt-Modell
von Excel befaï¿œt, und dort sind die VBA-Modul"blï¿œtter" versteckt. Ob Du
die Access-Codemodule ï¿œber das Access-Objekt manipulieren kannst?
Keine Ahnung! Kï¿œnnten vielleicht die Leute in den Access-Newsgroups
wissen. Oder in der deutschen Office Newsgroup.
Helmut.
BTW, den KW-Fehler kann man abfangen. Er tritt nur auf wenn das
fï¿œr die KW-Berechnung verwendete Datum der 29.12., 30.12. oder
31.12. *und* ein Montag ist *und* es eine ungerade Jahreszahl ist.
(und auch das nur in jedem 2. derartigen Fall).
d.h. ist der 29.12. ein Montag, so kann die Berechnung fï¿œlschlicherweise
KW53 liefern, doch fï¿œr Dienstag, den 30.12. des selben Jahres liefert
sie korrekt KW1
Ich hab das mal fï¿œr alle Daten der letzten 1000 und der nï¿œchsten 1500
Jahre nachgeprï¿œft, und der Fehler tritt *nur* bei Montagen auf die auch
die ï¿œbrigen genannten Kriterien erfï¿œllen.
Lothar Geyer
Am 28.03.2010 00:36, schrieb Helmut Meukel:
> ...
> wenn ich Dch richtig verstehe, so hast Du Access mit VBA programmiert und
> möchtest jetzt in die Datenbank(en) per VB6 ein Code-Modul mit dieser
> KW-Funktion reinschieben?
Nö. Ich verwende Access gar nicht (jedenfalls in diesem Umfeld) - nur
die Jet-Maschine. Die Anwendung ist vollständig in VB6 geschrieben. Auf
den Zielrechnern muss also kein Access installiert sein.
Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
(Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld vom
Typ DateTime und ein Feld vom Typ Long. Und die Abfrage soll die
Wochensummen liefern.
> Wenn das überhaupt geht, dann kann ich mir das nur über Automatisierung
> von Access vorstellen. Ich habe mich bisher nur mit dem Objekt-Modell
> von Excel befaßt, und dort sind die VBA-Modul"blätter" versteckt. Ob Du
> die Access-Codemodule über das Access-Objekt manipulieren kannst?
> Keine Ahnung! Könnten vielleicht die Leute in den Access-Newsgroups
> wissen. Oder in der deutschen Office Newsgroup.
Mit anderen Worten: Ohne Access geht das gar nicht?
> BTW, den KW-Fehler kann man abfangen. Er tritt nur auf wenn das
> für die KW-Berechnung verwendete Datum der 29.12., 30.12. oder
> 31.12. *und* ein Montag ist *und* es eine ungerade Jahreszahl ist.
> (und auch das nur in jedem 2. derartigen Fall).
Die Funktion selber ist nicht das Problem, nur das "Verwalten" derselben.
Lothar Geyer
Helmut Meukel
> Hallo Helmut,
>
> Am 28.03.2010 00:36, schrieb Helmut Meukel:
>> ...
>> wenn ich Dch richtig verstehe, so hast Du Access mit VBA programmiert und
>> möchtest jetzt in die Datenbank(en) per VB6 ein Code-Modul mit dieser
>> KW-Funktion reinschieben?
>
> Nö. Ich verwende Access gar nicht (jedenfalls in diesem Umfeld) - nur die
> Jet-Maschine. Die Anwendung ist vollständig in VB6 geschrieben. Auf den
> Zielrechnern muss also kein Access installiert sein.
>
> Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
> (Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld vom Typ
> DateTime und ein Feld vom Typ Long. Und die Abfrage soll die Wochensummen
> liefern.
>
Hallo Lothar,
Ich bin mir nicht 100% sicher aber ich meine eine selbst programmierte Access-
Funktion kann man nur aus Access heraus in einer SQL-Abfrage verwenden,
nicht aus VB6 heraus mit Jet.
Bei Deinem Ziel Wochensummen zu ermitteln ist die richtige Kalenderwoche
aber nur die halbe Miete. Wenn Du nur die KW berücksichtigst so würde Dir
z.B. für den 11.1.2008 die KW 1 geliefert. Für den 29.12.2008 aber auch
KW 1 !!! Die Zahlen für diese Tage sollten aber doch nicht in die selbe
Wochensumme eingehen, oder? Du brauchst also noch das KW-Jahr, das in
diesem Beispiel für den 29.12.2008 (u.ff.) das Jahr 2009 ist.
Für den 1., 2. und 3.Januar 2010 ist es umgekehrt, deren Zahlen gehören zur
KW 53 von 2009.
Ich würde eine zusätzliches Feld in der DB-Tabelle führen: "JahrKW" als Long
berechnet aus KW-Jahr*100 + KW.
Das kannst Du dann in der SQL-Abrage als Kriterium für die Summenbildung
verwenden. Sollte die Ausführung der Abfrage zudem beschleunigen.
Ob man dieses Feld automatisch mit berechnet wenn der Datensatz erzeugt
wird oder es - falls noch leer - erst berechnet und einträgt kurz bevor man die
SQL-Abrage startet, hängt von den Umständen ab.
Helmut.
Peter Fleischer
> ...
> Nö. Ich verwende Access gar nicht (jedenfalls in diesem Umfeld) - nur die
> Jet-Maschine. Die Anwendung ist vollständig in VB6 geschrieben. Auf den
> Zielrechnern muss also kein Access installiert sein.
Hi Lothar,
in diesem Fall kannst du auch nicht die Innereien von Access nutzen, d.h.,
du musst dich auf den Funktionsumfang von SQL beschränken, Und da gibt es
keine Wochenfunktion. Mit dem SQL server, D" oder Oracle wäre das möglich
mit einer Serveranwendung, mit der man zusätzliche Funktionen (UDF)
bereitstellen kann.
> Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
> (Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld vom
> Typ DateTime und ein Feld vom Typ Long. Und die Abfrage soll die
> Wochensummen liefern.
Und warum lässt du dir nicht Tagessummen bereitstellen und führst die
Wochenzuordnung dann im Programm aus?
> ...
> Mit anderen Worten: Ohne Access geht das gar nicht?
s. vorher (Tagessummen und Wochensummen per Code). Du könntest eine
übergeordnete Tabelle erstellen (MSDataShape), in der auf die Datensätze aus
der Child-Tabelle verwiesen wird, indem du per Code in der Child-Tabelle
(=Tagessummen) die Wochennummer einträgst, die dann mit der Master-Tabelle
korrespondiert.
--
Viele Gruesse
Peter
Peter Götz
> Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
> (Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld vom
> Typ DateTime und ein Feld vom Typ Long. Und die Abfrage soll die
> Wochensummen liefern.
Ein Feld vom Typ DateTime kann Dir u.a. auch eine
Kalenderwoche liefern. So weit kann ich Deiner Beschreibung
noch folgen.
Aber was genau sollte dann in diesem Feld vom Typ Long
stehen. Ich verstehe nicht was Du mit "Wochensummen"
meinst.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)
Lothar Geyer
Am 28.03.2010 13:54, schrieb Helmut Meukel:
> ...
> Ich bin mir nicht 100% sicher aber ich meine eine selbst programmierte
> Access-
> Funktion kann man nur aus Access heraus in einer SQL-Abfrage verwenden,
> nicht aus VB6 heraus mit Jet.
das wäre natürlich nicht schön. Ich kann mir zwar den gesamten Recordset
holen und das selbst rausrechnen, da es aber mit dem SQLserver geht,
hätte ich das gerne mit Jet auf die selbe Art erledigt.
> Bei Deinem Ziel Wochensummen zu ermitteln ist die richtige Kalenderwoche
> aber nur die halbe Miete. Wenn Du nur die KW berücksichtigst so würde Dir
> z.B. für den 11.1.2008 die KW 1 geliefert. Für den 29.12.2008 aber auch
> KW 1 !!! Die Zahlen für diese Tage sollten aber doch nicht in die selbe
> Wochensumme eingehen, oder? Du brauchst also noch das KW-Jahr, das in
> diesem Beispiel für den 29.12.2008 (u.ff.) das Jahr 2009 ist.
> Für den 1., 2. und 3.Januar 2010 ist es umgekehrt, deren Zahlen gehören zur
> KW 53 von 2009.
Das ist mir schon klar - lässt sich aber auch per Funktion aus dem Datum
herausnehmen - so das denn möglich ist.
Lothar Geyer
Wilfried Dietrich
> damit ich in einer SQL-Abfrage Wochensummen ermitteln kann.
vielleicht meinst Du sowas:
"SELECT DATEPART('WW',Datumfeld,2,2) As Wochennummer, SUM(DeinLongfeld) As DeineSumme
FROM ... WHERE(...)
GROUP BY DATEPART('WW',Datumfeld,2,2)"
Gruß
Wilfried
Lothar Geyer
Am 29.03.2010 12:12, schrieb Wilfried Dietrich:
>> damit ich in einer SQL-Abfrage Wochensummen ermitteln kann.
> vielleicht meinst Du sowas:
>
> "SELECT DATEPART('WW',Datumfeld,2,2) As Wochennummer, SUM(DeinLongfeld) As DeineSumme
> FROM ... WHERE(...)
> GROUP BY DATEPART('WW',Datumfeld,2,2)"
genau, nur dass eben die DatePart-Funktion in manchen Fällen ein
falsches Ergebnis liefert und ich deswegen eine eigene Funktion einbauen
muss.
Lothar Geyer
Lothar Geyer
Am 28.03.2010 16:21, schrieb Peter Fleischer:
>> ...
>> Nö. Ich verwende Access gar nicht (jedenfalls in diesem Umfeld) - nur
>> die Jet-Maschine. Die Anwendung ist vollständig in VB6 geschrieben.
>> Auf den Zielrechnern muss also kein Access installiert sein.
>
> Hi Lothar,
> in diesem Fall kannst du auch nicht die Innereien von Access nutzen,
> d.h., du musst dich auf den Funktionsumfang von SQL beschränken, Und da
> gibt es keine Wochenfunktion. Mit dem SQL server, D" oder Oracle wäre
> das möglich mit einer Serveranwendung, mit der man zusätzliche
> Funktionen (UDF) bereitstellen kann.
Ich hatte irgendwie sowas im Hinterkopf - wollte aber unbedingt mit dem
Kopf durch die Wand.
>> Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
>> (Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld
>> vom Typ DateTime und ein Feld vom Typ Long. Und die Abfrage soll die
>> Wochensummen liefern.
>
> Und warum lässt du dir nicht Tagessummen bereitstellen und führst die
> Wochenzuordnung dann im Programm aus?
Das ist die 2.-performanteste Lösung. Pro Tag können da ungefähr 15.000
Sätze sein, weshalb ich eben so viel als möglich direkt von der
Datenbank-Engine erledigt haben wollte (was bei Jet natürlich nur
bedingt möglich ist).
>> ...
>> Mit anderen Worten: Ohne Access geht das gar nicht?
>
> s. vorher (Tagessummen und Wochensummen per Code). Du könntest eine
> übergeordnete Tabelle erstellen (MSDataShape), in der auf die Datensätze
> aus der Child-Tabelle verwiesen wird, indem du per Code in der
> Child-Tabelle (=Tagessummen) die Wochennummer einträgst, die dann mit
> der Master-Tabelle korrespondiert.
Da bin ich (bzw. die Datenbank) mit einem reinen Recordset der
Tagessummen aber schneller, oder?
Lothar Geyer
Lothar Geyer
Am 28.03.2010 19:16, schrieb Peter Götz:
>> Und nun brauche ich eine SQL-Abfrage in meiner Anwendung, die
>> (Kalender-)Wochensummen ermittelt. Also eine Tabelle mit einem Feld vom
>> Typ DateTime und ein Feld vom Typ Long. Und die Abfrage soll die
>> Wochensummen liefern.
>
> Ein Feld vom Typ DateTime kann Dir u.a. auch eine
> Kalenderwoche liefern. So weit kann ich Deiner Beschreibung
> noch folgen.
> Aber was genau sollte dann in diesem Feld vom Typ Long
> stehen. Ich verstehe nicht was Du mit "Wochensummen"
> meinst.
ganz einfach: die Summe aller Long-Felder, aufsummiert nach
Kalenderwochen. Also die Long-Werte aller Records, deren DateTime-Value
in Kalenderwoche 01/2010 liegt, aufsummieren. Das gleiche für KW 02/2010
usw.
Lothar Geyer
Peter Fleischer
> ...
>> Und warum lässt du dir nicht Tagessummen bereitstellen und führst die
>> Wochenzuordnung dann im Programm aus?
>
> Das ist die 2.-performanteste Lösung. Pro Tag können da ungefähr 15.000
> Sätze sein, weshalb ich eben so viel als möglich direkt von der
> Datenbank-Engine erledigt haben wollte (was bei Jet natürlich nur bedingt
> möglich ist).
Hi Lothar,
ich verstehe nicht, warum die Zusammenfassung auf 52 Wochen einen
signifikanten Unterschied geben soll gegenüber der Zusammenfassung über
365/366 Tage.
>>> ...
>>> Mit anderen Worten: Ohne Access geht das gar nicht?
>>
>> s. vorher (Tagessummen und Wochensummen per Code). Du könntest eine
>> übergeordnete Tabelle erstellen (MSDataShape), in der auf die Datensätze
>> aus der Child-Tabelle verwiesen wird, indem du per Code in der
>> Child-Tabelle (=Tagessummen) die Wochennummer einträgst, die dann mit
>> der Master-Tabelle korrespondiert.
>
> Da bin ich (bzw. die Datenbank) mit einem reinen Recordset der Tagessummen
> aber schneller, oder?
Dann zeige mal die Messergebnisse. Ich bezweifle, dass die Zusammenfassung
von 105.000 Datensätzen mit dem Ergebnis von 52 Datensätzen im Recordet
signifikant schneller ist als die Zusammenfassung von 15.000 Datensätzen mit
dem Ergebnis von 52 Datensätzen? Die Differenz ist praktisch bestimmt ohne
Bedeutung.
--
Viele Gruesse
Peter
Lothar Geyer
Am 29.03.2010 22:10, schrieb Peter Fleischer:
> ...
> ich verstehe nicht, warum die Zusammenfassung auf 52 Wochen einen
> signifikanten Unterschied geben soll gegenüber der Zusammenfassung über
> 365/366 Tage.
bei einer Access-Datenbank sicher kaum ein Unterschied.
Beim SQLserver ergibt sich aber schon eine wesentliche geringere
Netzbelastung. Die Summe CPU-Zeit Server + Client ist wohl auch eher gleich.
Da ich sowohl Access als auch SQLserver unterstütze und strukturelle
Unterschiede möglichst vermeiden will, habe ich eben nach einem Weg
gesucht, die SQLserver-Lösung "auf Jet zu transferieren".
>>>> ...
>>>> Mit anderen Worten: Ohne Access geht das gar nicht?
>>>
>>> s. vorher (Tagessummen und Wochensummen per Code). Du könntest eine
>>> übergeordnete Tabelle erstellen (MSDataShape), in der auf die Datensätze
>>> aus der Child-Tabelle verwiesen wird, indem du per Code in der
>>> Child-Tabelle (=Tagessummen) die Wochennummer einträgst, die dann mit
>>> der Master-Tabelle korrespondiert.
>>
>> Da bin ich (bzw. die Datenbank) mit einem reinen Recordset der
>> Tagessummen aber schneller, oder?
>
> Dann zeige mal die Messergebnisse. Ich bezweifle, dass die
> Zusammenfassung von 105.000 Datensätzen mit dem Ergebnis von 52
> Datensätzen im Recordet signifikant schneller ist als die
> Zusammenfassung von 15.000 Datensätzen mit dem Ergebnis von 52
> Datensätzen? Die Differenz ist praktisch bestimmt ohne Bedeutung.
Messergebnisse habe ich keine - ich hatte ja nach Deiner Meinung
gefragt. Und die Frage bezog sich auf die Lösungen mit einem
hierarchischen und einem nicht hierarchischen Recordset.
Dass sich dabei größere Unterschiede nur bei einem entsprechend großen
Berichtszeitraum ergeben werden/würden, ist schon klar.
Lothar Geyer
Peter Götz
das eigentliche Problem ist also, eine Abfrage, welche
Dir Datensätze zu einer bestimmten Kalenderwoche
liefert ohne DatePart(), welches teilweise falsche
KW-Werte liefert, zu benutzen.
Aus der Kalenderwoche (Jahr, KW-Nummer) kannst
Du zwei "Datümer", erster Tag (Montag) und letzter
Tag (Sonntag) der Woche ermitteln.
Mit diesen beiden Tagen kannst Du dann eine
entsprechende Where-Klausel in Deinem SQL-String
bilden. Die Function MoKw liefert das Datum für den
ersten Tag (Montag) der jeweiligen KW.
Public Function MoKW(ByVal Jahr As Integer, ByVal KW As Integer) As Date
' KW1 (nach ISO) ist die Woche, in welcher der _
erste Donnerstag des Jahres liegt.
Dim datFirst As Date
Dim intWD As Integer
datFirst = DateSerial(Jahr, 1, 1)
intWD = Weekday(datFirst, vbMonday)
If intWD > 4 Then
datFirst = DateAdd("d", 8 - intWD, datFirst)
Else
datFirst = DateAdd("d", -intWD + 1, datFirst)
End If
MoKW = DateAdd("ww", KW - 1, datFirst)
End Function
Public Sub AnySub()
Dim DateFrom As Date
Dim DateTo As Date
DateFrom = MoKW(2010, 15)
DateTo = DateAdd("d", 6, DateFrom)
Dim strSQL As String
Dim Par1 As ADODB.Parameter
Dim par2 As ADODB.Parameter
Par1 = New ADODB.Parameter
With Par1
.Name = "@DateFrom"
.Type = adDate
.Value = DateFrom
End With
With par2
.Name = "@DateTo"
.Type = adDate
.Value = DateTo
End With
strSQL = ".... blablabla ....Where Datum Between ? And ?"
End Sub