Office: (Office 2007) DLookUP Ersatz deutlich langsamer als Zugriff per lokalem (im Modul) RecordSet

Hallo zusammen,

ich verwende in einer neuen Datenbank wie bisher eine Ersatzfunktion für die DLookUp-Variante.

Die entsprechende Codezeile innerhalb des Moduls sieht so aus:
Code:

Der Aufruf erfolgt per FCount("UserID", m_UserTableName, "UserID='" & m_UserID & "'") > 0
m_UserTableName und m_UserID sind lokale, bereits befüllte Variablen.

Die auszulesende Tabelle ist verknüpft und liegt auf einem Server im Netzwerk.
Der Zugriff bzw. bis ich das Ergebnis erhalte dauert ca. 1-3 Sekunden *entsetzt

DCount benötigt nahezu gleich lange.
Änderung von CurrentDB auf CodeDbC bringt keine merkliche Besserung.

Wenn ich statt FCount ein lokales RecordSet öffne und per SQL auswerte bekomme ich in 0 Then[/quote] Irgendwelche Ideen woran das liegt?
Ich kanns mir nicht erklären *frown.gif*

:)

 

Hallo!

einmal verwendest du dbReadOnly (eigentlich verwendest du dbOpenSnapshot) und einmal dbOpenForwardOnly.

Außerdem: einmal muss gezählt werden und einmal nur das Recordset geöffnet werden.
=> Falls bei der Count-Anweisung kein Index läuft, dauert das eben etwas länger, da alles Datensätze durchgezählt werden müssen.

=> Äpfel mit Birnen verglichen! *wink.gif*

Tipp: Falls du nur auf Existens eines DS prüfen willst, verwende die Lookup-Ersatzfunktion bzw. schreib dir eine Exists-Funktion.

Beispiel:
Code:

[OT]
Code:

Wie kann ein String NULL sein?
.. Das wäre wieder etwas für den VBA-Inspector. *wink.gif*

mfg
Josef

 

Danke schonmal für die Hinweise.
Das Codefragment ist aus einem Modul, dass ich glaube hier aus dem Forum habe... das mit dem criteria$ stimmt dennoch und wird bereinigt.
Schande über mein Haupt...

Wenn ich Dich richtig verstehe ist die von mir verwendete Domänenersatzfunktion "optimierungsbedürftig"... dann setz ich mich mal daran... und teste wieder.

Zu VBA-Inspector: Frag mich nicht wieso, aber hier in der Firma läuft der nicht... Daheim wird er natürlich eingesetzt und hat mir schon zigfach geholfen.

 

Hallo!

FCount macht schon das was es soll. Du hättest nur ein "FExists" mit der Recordset-Beispiel vergleichen sollen, da Count und nur OpenRecordset ohne zählen nicht vergleichbar ist. => Falscher Einsatz von FCount, wenn du die Existenz eines Datensatzes wissen willst.

Einen Verdacht habe ich noch: Falls UserID ein Primärschlüsselfeld ist und trotzdem kein Index-Seek erfolgt, könnte das am Textvergleich liegen, falls UserID ein Zahlenfeld ist.

Bezüglich Lookup & Co.:
Schau dir einmal die Klasse DaoHandler an ... vielleicht findest du ein paar Anregungen.

... eine ähnliche Klasse wird es demnächst auch in einer .NET-COM-dll geben. *wink.gif*

mfg
Josef

 

Ok, verstanden.
Das mit dem Exists leuchtet ein und ärgert mich dass ich da ein Brett vor dem Kopf hatte *stupid

Deinen DaoHandler schau ich mir gerade an... Gefällt mir sehr gut!
Ich hatte bisher nur simple Properties CurrentDbC und CodeDbC welche mir ein entsprechendes Objekt zurücklieferten.
Der Handler ist natürlich wesentlich eleganter...

 

Es gibt übrigens auch eine AdodbHandler und eine OdbcHandler und eine DbConnection-Klasse die diese alle zentral anbietet. *Smilie

mfg
Josef

[OT]
.. und jetzt noch etwas Werbung, da es thematisch zu den Klassen passt:
forum.access-codelib.net: .NET-Klassenbibliotheken für Access/VBA

 

Ich teste gerade den DaoHandler.
So ganz bin ich noch nicht durchgestiegen wie ich die einzelnen Methoden nutzen kann...

Spricht etwas dagegen mir eine globale Property zu setzen, welche eine Instanz der Klasse hält? Code:

Im If muss ich mir wohl noch ein Set m_DaoHandler.CurrentDb = CurrentDb gönnen, oder?

 

Hallo!

Ja, du musst der Klasse das passende Database-Objekt geben.
Ich wähle in dieser Klasse bewusst nicht CodeDb bzw. CurrentDb, damit man die Klasse auch für einen direkten Zugriff auf eine Access/Jet/ACE-Backend verwenden kann.

Das mit der Property ist sicher eine praktische Angelegenheit.
Schau dir eventuell auch DbConnectionHandler.cls an. Diese Klasse nutzt AdodbHandler, DaoHandler und OdbcHandler. Ich nutze diese Klasse als Einstiegspunkt für Datenzugriffe. (Dann muss ich die Verbindungselemente wie CurrentDb, Oledb- u. ODBC-Connectionstring nur einmal einstellen.)

Beispiel:
Code:

mfg
Josef

 

Ok, dann war ich da nicht ganz auf dem Holzweg.
Funktioniert soweit einwandfrei, allerdings ist die Performance auch nicht besser *wink.gif*
Aber zumindest hab ich was gelernt...
Ich habe die Befürchtung dass die Performance im Netzwerk begründet liegt; das hat heute immer wieder Probleme...

Ich habe jetzt gänzlich auf einen DLookUp-Einsatz oder eine Alternative verzichtet und nutze nur die Methoden des DaoHandlers.

Ein FExists bzw. Exists müsste ich ggf. auch dort implementieren, oder?

 

Hallo!

Ich hab auch nicht erwartet, dass die Auswertung mit dem DaoHandler schneller ist.
Count bleibt Count - egal von wo aus man es aufruft. *wink.gif*

Ist UserID das PK-Feld? Falls ja, welchen Datentyp hat es?

mfg
Josef

 

Glaub ich war am Freitag irgendwie nicht auf der Höhe...
Ich schau mir das heute nochmal an.

UserID ist ein indiziertes Textfeld und der PrimaryKey der Tabelle.
Zur Erklärung: Das ganze ist Teil einer Userklasse, welche ich beim Start der Anwendung instanziere.
Hier geht es konkret darum, fest zu stellen ob der angemeldete User überhaupt in der Tabelle existiert.

 

Wird irgendwie nicht besser... jetzt bekomme ich beim ausführen von DaoHandler.OpenRecordset einen 3001 wenn ich die optionalen Parameter fülle.
Der "native" Zugriff ist wie folgt möglich: Code:

Über den DaoHanlder klappt es nicht Code:

Die Tabelle ist eine verknüpfte JET-Tabelle.
Habe es auch mit dbOpenForwardOnly und dbOpenDynaset erfolglos probiert... Was übersehe ich?

Wenn ich keine optionalen Parameter fülle/setze klappt der Zugriff.

BTW: Der DaoHandler selbst gefällt mir sehr gut!

 

Hallo!

Wenn du dbReadOnly als 3. Parameter verwenden willst, musst du die Prozedur in der Klasse anpassen.
DAO.OpenRecordset erlaubt da ein ziemliches Misch-Masch - siehe OH.

Code:

mfg
Josef

 

Aaaaaaah.... *stupid
Wie war das mit dem Wald und den Bäumen. Danke fürs Holzfällen Josef.