Scrollen in Tabelle wird "Arschlahm"

[Mathias Fabian]

Hallo, hab mal wieder ein "für mich" nicht verständliches Problem

Also ich öffne eine Tabelle mittels eines TTable Objektes. Dies dauert schonmal so 3 Sekunden (eigentlich zu viel aber es sind halt so 25000 Datensätze). Jetzt kann ich mittels "Prior" und "Next" und so durch die Ergebnismenge blättern. Das Blättern dauert so ca. 0 bis 10 ms, was voll OK ist. Aber jetzt das Problem. Wenn ich jetzt z.B. ein TQuery erzeuge, einen SQL String (auf eine andere Tabelle!!) festlege, diesen ausführe und wieder zerstöre geht das auch ruckzuck. Wenn ich jetzt aber wieder in meinem Table scrollen will dauert das geschlagene 1200 bis 2400 ms!! was natürlich vollkommen inakzeptabel ist.

Als Datenbank benutze ich MS Access 97.

[Mathias Fabian]

OK, hab das Problem gefunden (glaub ich). Hab aber noch keine Lösung!!
<BR>
Es wird scheinbar die gesamte Tabelle beim öffnen in den Speicher geladen, der ist ruckzuck voll und alles wird auf platte ausgelagert.
<BR>
Ich verwende nicht den "normalen" MS Access Treiber in der BDE sondern ich gehe über den ODBC Treiber. Bei dem "normalen" Accesstreiber tritt das Problem nicht auf. Wie kann ich also verhindern das die Tabelle so übel gecached wird. Oder ist das der falsche Lösungsansatz??

MfG
Mathias Fabia

[Bernhard Geyer]

Ich würde bei Access die BDE aussen vor lassen und auf die ADO/ADOExpress-Schnittstelle wechseln. Damit hat man wieder bessere Kontrolle das Verhalten der DB-Schnittstelle, da weniger Zwischenschichten beteiligt sind. Und je mehr zwischenschichten beteiligt sind, desto geringer sind die Kontrollmöglichkeiten.

Folgendes soll dir verdeutlichen, das ADO/ADOExpress die beste Lösung ist:

"Funktsionstack" beim Zugiff auf Access je nach Zugriffsweg:

BDE mit MSAccess-Treiber (DAO):<br>
Application -> BDE -> MSAccess (DAO-Schnittstelle) -> Datenbank

BDE mit ODBC-Treiber:<br>
Application -> BDE -> ODBC -> ADO/OLEDB-Treiber -> Datenbank

ADO-Direkt:<br>
Application -> ADO-Treiber für Access -> Datenbank

ADO-Express:<br>
Application -> ADOExpress -> ADO-Treiber für Access -> Datenbank

ADO ist die beste Möglichkeit, jedoch hat man mit ADOExpress den Vorteil von (Delphi-)Komponenten um seine DB zu verwenden.


Als weitere Möglichkeit wäre es (ohne Umbau der verwendeten Schnittstelle) die Ergebnissdatenmenge kleiner zu halten (über Filter bzw. WHERE-Bedinung in Query)

[Mathias Fabian]

Danke für die Antwort, das Problem ist nur das ich nicht einfach so festlegen kann, das ein komplettes Warenwirkschaftssystem jetzt auf ADO umgestellt wird. Es wurde (von oben) festgelegt das wir auf ODBC gehen sollen da da dieselben Kompnenten verwendet werden können wie wenn man direkt auf die BDE geht. Über Sinn oder Unsinn dieser Entscheidung kann man sicherlich diskutieren aber es ändert leider nichts an der Tatsache das ich die "Standard" Datenbankkomponenten nutzen muß. Gibt es denn keine Möglichkeit zu sagen das die Tabelle nicht komplett in den Speicher geladen werden soll

[Bernhard Geyer]

Über die Abkürzung ADO wäre dies möglich...

Leider weiß ich aber keinen Weg wie man dies über den Weg BDE->ODBC->JET einstellen kann

[Mathias Fabian]

Das glaub ich dir gerne das ADO der bessere oder richtigere Weg ist, jedoch werde ich nicht die Ressourcen (Finanziell und Personel) das ganze Programmpaket umzustellen. Daher brauche ich leidergottes eine Möglichkeit das so zu realisieren.

Gruß
Mathia

[Andreas Tengicki]

@Mathias

wenn du aus welchen nötigen oder unnötigen Gründen, dich für den Weg BDE - ODBC - JETEngine entschieden hast bzw. entschieden wurdest, dann müssen die Entscheidungsträger mit dieser Variante leben. Zusammen mit dem Einsatz von TTable, ist das sicherlich auch der ungünstigste aller Wege mit dem man auf Daten zugreifen kann,

denn Die BDE weiß nur, daß es via ODBC geht, dahinter kann was auch immer stecken, sie kann also nur sehr wenig voraussetzen. Das einfachtste und logischte ist daher erstmal datenkrallen und lokal weiterverarbeiten, daher die Kopie in den Hautspeicher. Wenn Du mit Filter oder SQL die Datenmenge eingrenzt, kannst Du das Problem vielleicht entschärfen