Office: Vgl. 2er DLookUp-Varianten

Hi,

sind folgende Anweisungen gleichwertig, bzw. wo liegen die Vor- u. Nachteile?
Zweck der Anweisungen/Funktionen: Übergabe eines einzelnen Wertes aus einer SQl-Abfrage an eine Variable.

Code:

und
Code:

1. Wird im ersten Fall eine Recordset geöffnet?
2. Wird es auch wieder geschlossen?
3. Ist (0) der Feldindex des Recordsets?

:)

 

Moin Frank,

Hast Du beide Varianten mal ausprobiert ???

ich bin nicht sicher, ob #1 überhaupt etwas liefert: die Prozedur OpenRecordset liefert eine Recordset-Objektvariable und die muss per 'set variable = ' zugewiesen werden. Auch die Schreibweise mit dem Index 0 habe ich noch nie gesehen.

#2 liefert NULL, wenn das RecordSet leer ist aber wenn nicht?
.fields(0) ist wiederum ein Objekt und die Zuweisung sollte per 'Set' erfolgen.
Code:

 

Hi Hans-Christian,

beides funktioniert einwandfrei und bringen das gleiche Ergebnis

Bei folgender SQL-Abfrage wird immer EIN Ergebnis geliefert:
Code:

liefert aber einen Fehler. Eigentlich logisch, da Fields ja kein definiertes Feld ist, sondern die Feld-Auflistung des Recordsets und da ist die !-Schreibweise IMHO falsch.

 

Die zweite Variante ist die von Josef P., wenn ich mich nicht schwer irre, und ist deswegen alleine schon sauber. Beim leeren Recordset wird analog DLookup Null zurückgegeben.
Bei der ersten Variante müsste man mal testen, wie der Umgang ist, wenn die SQL-Anweisung kein Ergebnis bringt. Das wird der einzige Knackpunkt sein.

 

Hallo Eberhard,

Da hast Du vollkommen recht und läuft natürlich auch hervorragend *Smilie

Code:

liefert NULL zurück, wobei tblLeer eine leere Tabelle OHNE Datensätze und Felder ist und daher die Funktion Max(ID) keinen Wert zurückgibt.

 

Code:

die eingeklammerte Zahl ist der Feldindex des Recordset. Hier der Filmtitel
Code:

hier die ID

!!! Bei dieser Schreibweise ist die Angabe des Feldindexes (n) scheinbar unbedingt erforderlich, da sonst Fehlermeldung !!!

 

Anm.:
Code:

steht für
Code:

weil Fields das Standardelement von Recordset ist.
CurrentDbC.OpenRecordset(...) ... liefert als Ergebnis ein Recordset, das man im Prinzip ohne Umweg einer Variablen verwenden kann.
symbolisch: [Recordset aus CurrentDbC.OpenRecordset(..)].Fields(0)

Wenn es keinen Datensatz gibt, kann aber Recordset.Fields(0) nicht ausgewertet werden und es kommt zu einem Fehler.

 

Hi Josef,

Danke, sowas in der Art hatte ich auch vermutet (siehe #6)

Hmmm.... NULL = Fehler ????? -> s. Posting #5

 

Nein, NULL führt zu keinem Fehler. Nur wenn kein DS vorhanden ist, kommt es zu einem Fehler.
z. B.:
Code:

oder
Code:

 

Jetzt musste ich doch einmal testen - und frage mich, was Du getestet hast.

Ich scheitere schon daran, eine Tabelle ohne Felder anzulegen.

Der gezeigte Test mit Max auf eine Tabelle ohne Datensätze ergibt in der Tat Null.

Der Test einer ganz normalen Auswahlabfrage (ebenso typisch für DLookup) mit
Code:

..., wobei ID 100 in der Tabelle nicht vorhanden ist, ergibt LZF 3021 (Kein aktueller Datensatz).

 

Hi Josef,

ich glaube ich hab's verstanden:
Bei existierenden Tabellen MIT Datensätzen kann ich die Kurzvariante nehmen

Wenn ich mir da mal nicht so sicher sein sollte, dann doch lieber die ausführliche Variante von Dir

 

\@Eberhard,

sorry das Du Dir die Arbeit gemacht hast, mein Problem nachzuvollziehen *upps

Ich hatte in der Tat nur folgende Zeile angetestet gehabt und die lieferte halt NULL:

Asche über mein Haupt *entsetzt
Bei leeren Tabellen gibts also meist Fehlermeldungen bei dieser Version

 

Die ausführliche Variante wird schnell kurz, wenn man sie in eine Hilfsfunktion steckt. (So wie im Beitrag #1 gezeigt)
Wenn dann später nur noch diese Hilfsfunktion verwendet wird, ist es doch völlig egal wieviele Zeilen in dieser Hilfsfunktion stecken.

Eine Funktion, die ich gerne einsetze:
Code:

=>
Code:

 

Wenn es mit Sicherheit den gewünschten Datensatz laut Kriterium gibt. Wer kann das schon sagen?

Ein Test, ob ein bestimmter Datensatz/Eintrag vorhanden ist, sollte somit mit der Kurzvariante tunlichst unterlassen werden.

Fazit: Die Langvariante ist universeller und in der Schreibarbeit kürzer, die einmalige Deklaration der Funktion (Kopieren in ein Modul) kann man als Aufwand vernachlässigen.