Wechsel von TTable zu TQuery

[MPirnstill]

Hi Leute!

Ich habe ein kleines Performance-Problem. Meine Anwendung verwaltet Studenten. In der Haupttabelle sind ca. 12000 Datensätze (und in Folge-Tabellen ca. 13 Folgesätze mit Ergebnissen usw. je Prüfling). Die Anwendung läuft auch recht flüssig. So jetzt gibt es ein neues Gesetz und die Prüflinge werden nach anderen Gesetzesgrundlagen geprüft. Ein Feld zur Kennzeichnung dieses Verfahren hab ich. Doch wenn ich jetz einen Filter setze wird das ganze schweine-langsam.
Okay, jetzt sagt ihr wahrscheinlich nimm doch TQuery, das will ich auch gerne tun, doch ich nutze bei der TTable die Methode Findkey um über den PI zu positionieren. Wie mache ich das am besten mit TQuery, denn da gibt es ja kein Findkey? Habe da irgendwie ein Brett vorm Kopf.

Würde mich über 'ne gute Idee freuen. Vielen Dank im Voraus.

[Jelly]

Probiers mal mit Locate anstatt FindKey.

[Union]

Du kannst auch in Query durch Casten auf TTable mit Findkey arbeiten, es ist allerdings etwas gefährlich und setzt voraus, dass Du einen entsprechenden Index mit order by definiert hast:
TTable(Query1).FindKey(Id);

[Bernhard Geyer]

Zitat von MPirnstill:

Ein Feld zur Kennzeichnung dieses Verfahren hab ich. Doch wenn ich jetz einen Filter setze wird das ganze schweine-langsam.

Wird vermutlich daran liegen das der Filter-Client-Seitig durchgeführt wird. Sprich der gesamte Datenbestand wird zum Client geschickt und erst dort analysiert.

Zitat von MPirnstill:

Okay, jetzt sagt ihr wahrscheinlich nimm doch TQuery, das will ich auch gerne tun, doch ich nutze bei der TTable die Methode Findkey um über den PI zu positionieren. Wie mache ich das am besten mit TQuery, denn da gibt es ja kein Findkey? Habe da irgendwie ein Brett vorm Kopf.

Wenn schon umbauen dann richtig. Schmeiß BDE mit TDatabase/TTable und TQuery komplett raus und welchel auf ADOExpress/dbGo (Noch besser wäre natürlich direkt auf die ADO-Native-Kompontenten) und bau dein Programm konsequent darauf um das solche Filterungen per SQL von der Datenbank erledigt werden. Bei geeigneten Indexen auf der Datenbank ist das auch sehr performant.

[MPirnstill]

Hi!

Erst mal vielen Danke für euere Antworten.

@Jelly
Danke für den Hinweis! Stimmt Locate gibt es ja auch, hatte ich irgendwie ganz vergessen. Werde mal ausprobieren, ob es damit geht.

@Union
Falls das mit dem Locate nicht klappt, wenn die TQuery nach TTable caste, wie muß ich diesen Index angeben. Reicht das, wenn ich einfach in Order By die beiden Primär-Index-Felder der Tabelle angebe?

@Bernhard
Generell gebe ich dir recht. Würde auch eine andere Zugriffsmethode für Datenbanken wählen, wenn ich ein neues Programm erstellen würde, aber dies ist eine bestehende, komplexe Anwendung (und auch noch in Delphi 2.0) und jetzt auf ADO oder dbGO umzustellen ist von der Zeit her nicht drin.

Zitat:

Wird vermutlich daran liegen das der Filter-Client-Seitig durchgeführt wird. Sprich der gesamte Datenbestand wird zum Client geschickt und erst dort analysiert.

Oder könnte man auch irgendwie über die BDE veranlassen, daß die Filterung Server-seitig durchgeführt wird?

Gruß

[Jelly]

Zitat von MPirnstill:

Oder könnte man auch irgendwie über die BDE veranlassen, daß die Filterung Server-seitig durchgeführt wird?

Ja, aber dann bist Du wieder bei TQuery. Mit TTable geht das definitiv nicht. Und wenn Du nun schon nach Query wechselt, dann machs wirklich gleich über ADO und vergiss die BDE ganz schnell.

[MPirnstill]

Zitat von Jelly:

Ja, aber dann bist Du wieder bei TQuery. Mit TTable geht das definitiv nicht. Und wenn Du nun schon nach Query wechselt, dann machs wirklich gleich über ADO und vergiss die BDE ganz schnell.

Leider betrifft dies 2 bestehende Anwendungen die beide so um die 44000 Zeilen Programmcode (lt. Delphi-Compiler) haben und außerdem habe ich mit ADO noch keine Erfahrung und kann mir irgendwie nicht vorstellen, daß mit Delphi 2.0 auf die schnelle so einfach wäre. An der Delphi Version kannst vielleicht auch erkennen, daß die Anwendungen schon einige Zeit im Einsatz sind. Ich wollte schon mal auf Delphi 7 gehen, daß die Entwicklungsumgebung viel komfortabler ist als in D2, jedoch hätte ich dann mal so zwischendurch 40 nicht simple Quick-Report neu machen müssen. Vielleicht bei der nächsten Änderung der Ausbildungsverordnung.

Gruß

[Jelly]

Laut deinem Profil nutzt du Delphi 2005 Enterprise. Wie soll ich erahnen dass Du Delphi 2 für die Anwendung verwendest... Ich glaube nicht dass Du mit Delphi 2 überhaupt ne Chance hast, ADO zu nutzen. Zumindest sind die VCL Komponenten nicht vorhanden.

Dann bleibt Dir also statt TTable die TQuery Kompo zu nehmen, und weiterhin bei der BDE zu bleiben. So tragisch ist das nun auch nicht, arbeite selbst noch an einem recht aufwendigen Projekt auf Basis der BDE.

[Bernhard Geyer]

Zitat von MPirnstill:

Ich wollte schon mal auf Delphi 7 gehen, daß die Entwicklungsumgebung viel komfortabler ist als in D2, jedoch hätte ich dann mal so zwischendurch 40 nicht simple Quick-Report neu machen müssen.

Quickreport ist doch AFAIK bei D7 auch dabei. Jedoch werden die entsprechenden Packages defaultmässig nicht in der IDE installiert.

[MPirnstill]

Zitat von Jelly:

Laut deinem Profil nutzt du Delphi 2005 Enterprise.

Sorry, ich hatte vergessen, dies mit in den Post zu schreiben. Aber ich hatte es in meiner Antwort erwähnt, allerdings in dem Part für Bernhard. D2005 bzw. D8 ist mal für Web-Programmierung angedacht gewesen, jedoch wurde das erstmal wieder auf Eis gelegt. Und wenn das Web-Projekt wieder aufgeriffen wird, wird es wohl mit Visual Studio sein, da D8 so rottig war. Mein Chef hatte zwar noch den Update auf 2005 geholt, ab aufgrund anderer Arbeiten konnte ich noch nicht richtig testen, ob das jetzt besser ist als D8.

Vielen Dank noch mal.