Recordset = Nothing - Abfrage ???
Thomas Tomiczek
abfrage=recordset.
Du bekommst ein Recordset, daß aber keine Rows enthält.
Thomas
<rbur...@htwm.de> wrote in message news:39A38C0C...@htwm.de...
> Hallo "Helfer", ich habe folgendes Problem :
>
> Den Umgang mit Datenbanken habe ich nach langen probieren
> nun endlich geschafft, leider noch nicht vollständig.
>
> Bei der Abfrage der DB mit einer SQL-Abfrage möchte ich
> das leere Recordset auswerten, d.h. wenn das Suchergebniss
> Null(kein Ergebniss gefunden) soll eine Anweisung ausgeführt
> werden.
> In etwa so :
> if Recodrset = Nothing then Msgbox
>
> leider klappt es nicht so einfach.Ich hoffe mir kann rasch
> geholfen werden und freue mich auf eine Antwort.
>
> Danke Ralf Burkhardt
Hoogo
>das leere Recordset auswerten, d.h. wenn das Suchergebniss
>Null(kein Ergebniss gefunden) soll eine Anweisung ausgeführt
>werden.
Da fallen mir 2 Abarten ein (DAO):
Normalerweise ist folgendes korrekt:
set rs=db.openrecordset ("SELECT * FROM Bla WHERE 1=0",dbopendynaset)
if rs.eof then msgbox("Kein Datensatz zurückgekommen")
Je nach Abfrage kannst Du aber auch ein Ergebnis zurückbekommen, das leer
ist:
set rs=db.openrecordset("SELECT FIRST(ZAEHLER) AS [A] FROM Bla WHERE
1=0",dbopensnapshot)
if isnull(rs!a) then msgbox("Warscheinlich nichts gefunden")
Ich bin mir nicht sicher, ob Funktionen wie first Nullwerte ignorieren, in
unserem Fall gibt es im Feld Zähler keine Null-Werte, falls notwendig, musst
Du das mal ausprobieren.
Frank/Hoogo
Michael Ronge
zuerst ein klein wenig Theorie: ein Recordset ist ein COM-Object. Wurde es
mit
Dim x as Recordset
instanziert, hat es den Inhalt Nothing (d. h. das Objekt ist nicht
"vorhanden", sondern es wurde nur eine Variable für die Aufnahme eines
Objekts vorbereitet). Wurde es mit
Dim x as New Recordset
oder
Set x = CreateObject("Recordset")
eingerichtet, enthält es ein gültiges, wenn auch "leeres" Objekt. Damit ist
es nicht mehr "Nothing" - obwohl noch gar keine Abfrage stattgefunden hat,
das Recordset noch nicht geöffnet ist usw.
Wurde das Recordset geöffnet (x.Open), enthält es immer noch das vorher
instanzierte Objekt, nur dessen Eingeschaften (Recordsource, Fields,
Recordcount etc.) haben sich geändert.
Die hier maßgebliche Eigenschaft ist Recordcount. Enthält Sie den Wert 0 (If
x.Recordcount = 0 Then doSomething), wurden keine Datensätze gefunden, ist
sie größer 0, gibt sie die Anzahl der gefundenen Datensätze an.
ACHTUNG: Wurde ein Recordset vom Typ adOpenDynamic mittels ADO auf einem
SQL-Server geöffnet, enthält Recordcount immer den Wert -1. Hier hilft dann
nur die Abfrage der Eigenschaft EOF (If x.EOF Then doSomething).
Wie Du siehst, gilt es hier, die Eigenschaften zweier unterschiedlicher
Technologien zu unterscheiden, die im Recordset vereint sind. Ich hoffe, das
war jetzt nicht zu abgehoben oder lehrerhaft ;-)
Gruß
MR
Ralf Wiesener
generell ist es rat einen recordset nicht über den recordcount auf daten
zu überprüfen.
man sollte lieber EOF und BOF abfragen. Sind beide Werte true dann
ist kein Recordset vorhanden
Gruß Ralf
Michael Ronge <sc...@snafu.de> schrieb in im Newsbeitrag:
39a3...@BASICWORLD.COM...
Andreas Schöpf
hast Du die Bestätigung dass das Recordset keine Datensätze enthält.
Mfg
Andreas
Peter Landau
"Mit Hilfe der IsNothing-Funktion können Sie feststellen, ob ein
Objektverweis auf Nothing gesetzt wurde." [Originalton, Hilfedatei]
Peter
Peter Götz
> zuerst ein klein wenig Theorie: ein Recordset ist ein COM-Object. ..
Grau ist alle (oder zumindest diese) Theorie
> Dim x as Recordset
> Dim x as New Recordset
> oder
> Set x = CreateObject("Recordset")
Recordset ist nicht gleich Recordset.
Bei einem DAO.Recordset geht das schlicht in die Hose.
Dim RS as DAO.Recordset
Set RS = New ADO.Recordset -->>> Fehler
> eingerichtet, enthält es ein gültiges, wenn auch "leeres" Objekt.
> Damit ist es nicht mehr "Nothing" - obwohl noch gar keine
> Abfrage stattgefunden hat, > das Recordset noch nicht
> geöffnet ist usw.
s. Recordset ist nicht gleich Recordset.
> Die hier maßgebliche Eigenschaft ist Recordcount.
> Enthält Sie den Wert 0 (If x.Recordcount = 0 Then doSomething),
> wurden keine Datensätze gefunden, ist sie größer 0,
> gibt sie die Anzahl der gefundenen Datensätze an.
> ACHTUNG: Wurde ein Recordset vom Typ adOpenDynamic
> mittels ADO auf einem SQL-Server geöffnet, enthält
> Recordcount immer den Wert -1.
mit SQL-Server hat das nicht unbedingt was zu tun.
> Hier hilft dann nur die Abfrage der Eigenschaft EOF
> (If x.EOF Then doSomething).
Recordset.MoveLast
Recordset.MoveNext
if Recordset.EOF then
if not Recordset.bof then
msgBox "Recordset ist keineswegs leer")
end if
end if
> Wie Du siehst, gilt es hier, die Eigenschaften zweier unterschiedlicher
> Technologien zu unterscheiden, die im Recordset vereint sind. Ich hoffe,
das
> war jetzt nicht zu abgehoben oder lehrerhaft ;-)
hmmm ??
Grüsse aus St.Georgen im Chiemgau,
Peter Götz p.g...@gssg.de
www.gssg.de (mit VB-Tips u. Beispielprogrammen)
Peter Götz
> "Mit Hilfe der IsNothing-Funktion können Sie feststellen, ob ein
> Objektverweis auf Nothing gesetzt wurde." [Originalton, Hilfedatei]
nicht alles, was in der Online-Hilfe steht, darf man glauben.
if Recordset is Nothing then
msgbox "so gehts besser"
end if
Ralf Wiesener
eigendlich schon, denn wenn einer da ist ist entweder Eof oder bof falsch
gruß ralf
Andreas Schöpf <Andreas...@t-online.de> schrieb in im Newsbeitrag:
39a40b9b$1...@BASICWORLD.COM...
Alexander Schmidt
Ich habe bei serverseitigen ADO-Recordset aber fast immer -1 als
RecordCount. Verallgemeinern kann man das also IMHO auch wieder nicht, oder
liege ich falsch?
Alex.
Peter Götz
Hallo Alexander,
Wenn Du einen serverseitigen Cursor bei einem ADO-Recordset meinst,
liegst Du mit Recordcount -1 richtig.
Deshalb habe ich auch geschrieben:
Recordcount = 0 heisst: Recordset leer
Alexander Schmidt
> Wenn Du einen serverseitigen Cursor bei einem ADO-Recordset meinst,
> liegst Du mit Recordcount -1 richtig.
>
> Deshalb habe ich auch geschrieben:
> Recordcount = 0 heisst: Recordset leer
Sorry, die Nacht war lang ... usw. usf. ;-)
Alex.
Michael Ronge
vielen Dank für Deinen Kommentar. Mit dem Inhalt Deiner Antwort habe ich
aber ein paar Probleme:
> Recordset ist nicht gleich Recordset.
> Bei einem DAO.Recordset geht das schlicht in die Hose.
mit DAO? Alle mir bekannten Bücher beschäftigen sich seit Jahren nur noch
mit ADO bzw. empfehlen dessen Einsatz.
> mit SQL-Server hat das nicht unbedingt was zu tun.
sollen, um das deutlich zu machen. Natürlich führt adOpenDynamic auch z. B.
bei einer Accessdatenbank zu einem RecordCount von -1.
> Recordset.MoveLast
> Recordset.MoveNext
> if Recordset.EOF then
> if not Recordset.bof then
> msgBox "Recordset ist keineswegs leer")
> end if
> end if
Recordset führt ein MoveLast oder MoveNext, angewendet auf eine leere
Tabelle/Abfrage zu einem Laufzeitfehler.
Michael Ronge
ich verstehe nicht, was es gegen RecordCount einzuwenden gibt. Es gab zwar
mit DAO das Problem, daß RecordCount bei einer Accessdatenbank erst korrekt
wiedergegeben wurde, wenn vorher ein MoveLast durchgeführt wurde. Das
Ergebnis war bei einem leeren Recordset trotzdem korrekt 0. Außerdem ist
dieses Problem bei ADO behoben, hier wird gleich der richtige Wert. Gibt es
da sonst noch etwas, von dem ich wissen sollte?
Gruß
MR
Thomas Tomiczek
es kann den ganzen Datentransfer langsamer machen. Normalerweise kann mir
der Server Daten liefern, während die Abfrage noch läuft.
Wenn ich ein korrektes Recordcount will, geht das nicht mehr.
Thomas Tomiczek
"Michael Ronge" <sc...@snafu.de> wrote in message
news:39a5...@BASICWORLD.COM...
Peter Götz
> > Recordset ist nicht gleich Recordset.
> > Bei einem DAO.Recordset geht das schlicht in die Hose.
> Das ist mir auch klar, aber wer programmiert als Neueinsteiger heute noch
> mit DAO? Alle mir bekannten Bücher beschäftigen sich seit Jahren nur noch
> mit ADO bzw. empfehlen dessen Einsatz.
welche Neueinsteiger noch oder nicht mehr mit DAO programmieren, weiss ich
nicht.
Wenn Du nur Bücher kennst, die sich mit ADO beschäftigen heisst das nicht
unbedingt, dass der Rest der Welt ausschliesslich ADO benutzt. Es gibt alle
möglichen Gründe neben ADO auch nach wie vor DAO zu benutzen. Ein ganz
simpler ist z.B. der: Der Kunde will es so.
Aber das ist nur einer von vielen Gründen.
> > Recordset.MoveLast
> > Recordset.MoveNext
> > if Recordset.EOF then
> > if not Recordset.bof then
> > msgBox "Recordset ist keineswegs leer")
> > end if
> > end if
> Dieser Abschnitt ist mir völlig unklar. Ausgehend von einem ADODB 2.5
> Recordset führt ein MoveLast oder MoveNext, angewendet auf eine leere
> Tabelle/Abfrage zu einem Laufzeitfehler.
bei einer leeren Tabelle ja. Aber die von Dir vorgeschlagene Methode, auf
EOF zu prüfen und bei RS.EOF=True darauf zu schliessen, das Recordset sei
leer, ist falsch.
EOF alleine sagt nichts darüber, ob ein Recordset Datensätze enthält oder
nicht.
Nur bei (RS.EOF and RS.BOF) = True ist das Recordset wirklich leer.
Thomas Tomiczek
"Peter Götz" <p.g...@gssg.de> wrote in message
news:39a56fa8$1...@BASICWORLD.COM...
> Hallo Michael,
>
> > > Recordset ist nicht gleich Recordset.
> > > Bei einem DAO.Recordset geht das schlicht in die Hose.
> > Das ist mir auch klar, aber wer programmiert als Neueinsteiger heute
noch
> > mit DAO? Alle mir bekannten Bücher beschäftigen sich seit Jahren nur
noch
> > mit ADO bzw. empfehlen dessen Einsatz.
>
> welche Neueinsteiger noch oder nicht mehr mit DAO programmieren, weiss ich
> nicht.
> Wenn Du nur Bücher kennst, die sich mit ADO beschäftigen heisst das nicht
> unbedingt, dass der Rest der Welt ausschliesslich ADO benutzt. Es gibt
alle
> möglichen Gründe neben ADO auch nach wie vor DAO zu benutzen. Ein ganz
> simpler ist z.B. der: Der Kunde will es so.
Tja, aber dann sollte man dem Kunden mal erklären, daß das was er will
schlecht ist. In diesem Fall würe ich darauf bestehen, daß ich schriftlich
bestätigt krietge, daß er die flgenden Gründe erklärt bekomment hat und mich
von ale rHaftung freistellt:
(a) mit DAO ist eine Aufrüstung auf den SQL Server zu einem späteren
Zeitpunkt nicht möglich, ohne das ganze neu zu programmieren.
(b) DAO wird von Microsoft seit einigen Jahren als Alttechnologie behandelt
und nicht mehr weiterentwickelt.
Und wenn er mir DAS abnimmt, dann bin ich ja aus jeder Haftung raus. Denn es
gibt eine Sorgfaltspflicht.
Thomas
Hoogo
Datensatz. Falls keiner da ist, ist EOF=True. Nur wenn diese Voraussetzung
nicht da ist, muß man auf .BOF und .EOF testen.
Ich persönlich ziehe DAO vor, solange es halt geht, ein Umsteigen bringt mir
nur Nachteile. Es gibt ODBC-Treiber für alle möglichen Datenbanken, mit
Providern sieht das anders aus. ADO hat noch eine Menge Fehler, diese NG ist
voll davon (DAO hat allerdings auch mal so seine Macken). Ich brauche selten
mehr als das Öffnen von Recordsets oder das Ausführen von SQL-Sprüchen, neue
Funktionen in ADO würde ich warscheinlich kaum nutzen (vielleicht würde ich
auch jubeln, wer weiss...). Ein Umstieg hätte zur Folge, daß einige viele
Rechner bei Kunden und intern neu installiert werden müssten, die alle schon
mit DAO und den Basic-Runtimes ausgestattet sind. Ich kann "mal eben" was in
Access-VBA ausprobieren und in mein Basic-Programm übernehmen. Und man muß
auch nicht den Code ändern, damit Programme mal auf Access, mal auf
SQL-Server oder anderen Datenbanken laufen.
Nur weil Persil jetzt Megaperls heisst, wird die Wäsche nicht weißer.
Frank/Hoogo
Peter Götz
Thomas Tomiczek <th...@gmx.de> schrieb in im Newsbeitrag:
39a5fc05$1...@BASICWORLD.COM...
> .....
> Tja, aber dann sollte man dem Kunden mal erklären, daß das was er will
> schlecht ist. In diesem Fall würe ich darauf bestehen, daß ich schriftlich
> bestätigt krietge, daß er die flgenden Gründe erklärt bekomment hat und
mich
> von ale rHaftung freistellt:
Wann wirst Du endlich begreifen, dass es auf der Welt ausser Deiner eigenen,
auch noch andere Meinungen gibt. Meine Kunden und sicher nicht nur diese
sind keine ignoranten Neandertaler, denen ich als der grosser Meister erst
mal die Grundlagen der Datenverarbeitung beibringen muss. Die sind durchwegs
intelligent genug, ihre eigenen Entscheidungen zu treffen. Wenn sie Beratung
oder sonstige Hilfestellungen brauchen, sagen die das und vor allem wissen
sie auch sehr genau, wie sie zu einer kompetente Beratung bekommen. Da muss
ich mich nicht als Oberlehrer aufspielen. Bei Deiner obigen Bemerkung werde
ich auch das Gefühl nicht los, dass Du noch nie einen wirklichen Vertrag
über einen Softwareentwicklungsauftrag gesehen hast.
> (a) mit DAO ist eine Aufrüstung auf den SQL Server zu einem späteren
> Zeitpunkt nicht möglich, ohne das ganze neu zu programmieren.
Mir ist keine Gesetzesvorschrift bekannt, die besagt, dass eine Software von
irgendeinem Datenbanksystem auf SQL-Server umgerüstet werden muss. Mir sind
aber dutzende von Gründen bekannt, warum es in vielen Fällen zur Lösung
eines bestimmten Problems günstiger ist, ein anderes Datenbanksystem zu
verwenden. Das ist keine Wertung für oder gegen SQL-Server.
> (b) DAO wird von Microsoft seit einigen Jahren als Alttechnologie
behandelt
> und nicht mehr weiterentwickelt.
Na dann haben sich die noch vor gar nicht so langer Zeit erschienenen
Jet-Versionen 3.6 u. 4.0 wohl von selbst entwickelt. Ich war bis zum
heutigen Tag der Meinung, die Firma Microsoft wäre dafür verantwortlich.
> Und wenn er mir DAS abnimmt, dann bin ich ja aus jeder Haftung raus. Denn
es
> gibt eine Sorgfaltspflicht.
Bis heute hat mir noch keiner meiner Kunden vorgeworfen, ich habe bei der
Entwicklung der für ihn bestimmten Software nicht die nötige Sorgfalt walten
lassen. Auch verspüre ich nicht die geringste Neigung mich aus der "Haftung"
für die von mir ausgeführten Aufträge zu stehlen. Auf die Vorstellungen und
Wünsche eines Kunden einzugehen ist auf Dauer wohl doch der
erfolgversprechendere Weg.