Hallo Allerseits,

leider habe ich hier mit meiner geschriebenen Delphi-Anwendung etwas Probleme. Diese Anwendung spricht drei verschiedene Datenbanken an. Auf meinen Entwicklungssystem startet die Anwendung ohne Probleme. Bei einem Nutzer, bei dem ich das Programm instalkiert habe, läuft es nicht an. Es kommt kein Bildschirmfenster, keine Fehlermeldung, nichts....

Bei einem anderen Anwender liess sich die Anwendung anstandslos starten.

Ich habe an die BDE gedacht, vielleicht geben da unterschiedliche Softwarestände den Ausschlag.. Aber auch die Überprüfung der vorhandenen BDE auf den Arbeitsplatzrechner brachte keine Lösung.

Eine elegante Lösung wäre sicherlich der Einsatz der ADO-Schnittstelle. Nur habe ich da bei einer Tabelle andere Schwierigkeiten mit der Anzahl der Datensätze einer Tabelle, die sich auf rund 400.000 beläuft. Trotz Einsatzes eines Primary-Keys gibt es lange Wartezeiten, die eigentlich inakzeptabel sind. Vielleicht weiss da auch jemand bescheid drüber..


Vielen Dank


Peter

Wie wann setzt du den Connectionstring?
BTW: BDE sollte weg.

Den Connectionstring setze ich zur Entwicklungszeit im Objektinspektor. Dazu muss ich allerdings sagen, das ich mit der Vorgehensweise bei ADO-Verbindungen noch nicht so fit bin..


Warum muss die BDE weg. Auf der anderen Seite kann ich die BDE'n auf dem Arbeitsplatzrechnern nicht einfach löschen, da diese von anderen, mir fremden Anwendungen benutzt wird

Ich meinte auch du solltest die BDE-Abhängigkeit deines Programmes entfernen und auf was anderes umstellen.

hallo mkinzler,


das würde ich liebend gerne machen. Nur wie gesagt, bei einer tabelle habe ich grosse Perfomanceprobleme. Sie beinhaltet ca. 400.000 Datensätze.

Bei anderen Tabellen mit geringeren Datensätzen habe ich nicht das Problem. Mittlerweile habe ich verschiedene Hardwareplattformen mit MS-SQL getestet. leider bringt es mir immer die gleichen schlechten Resultate..

Ich versuch es mal mit einem Bild:
Du ziehst einen Vw-Käfer mit deinem Mofa. weil dir die sache zu langsam ist, motzt du nun den Vw auf und wunderst dich, dass es immer noch nicht schneller geht.

Hallo,

BDE muss weg, ja (huch, ich nutz die ja auch )

Ich würde mal nach der Ursache suchen,
warum es bei ADO nicht geht.

1. Was konkret machst du auf der 400000er Tabelle,
was so langsam ist.
Du solltest du anfangen zu suchen.
ADO sollte bei ms-sql schneller sein.

2. Cursor-Einstellungen prüfen (muss entweder auf Server oder Client gesetzt werden,
Server ist schneller)

3. Traffic-Monitor benutzen (such hier mal, ansonsten PM an micht)
wenn du 400000 Datensätze übers Netz ziehst, selber Schuld ...

4. wie 3.
ein Select * From Table_400000
ist nicht wirklich ratsam

5. stored procedures (TSQL) benutzen

6. immer !
Den SQL-Sever immer auf einen anderen Rechner packen !!!

Ich kenne den Spruch: "Bei mir lokal ist es schnell, aber im Netz extrem langsam"


Zu dem Connection-Problem.
Der Connection-String gehört ausgelagert, Registry, conf-Datei, Ini (Achtung, Vista).
Das Connect sollte in einem try except und der Nutzer zumindestens darauf hingewiesen werden,
wenn das Connect fehlschlägt.

Da müsste doch ne Exception kommen.


Heiko

Zitat von fly_singapore:

das würde ich liebend gerne machen. Nur wie gesagt, bei einer tabelle habe ich grosse Perfomanceprobleme. Sie beinhaltet ca. 400.000 Datensätze.

400.000 Datensätze - Und wo ist das Problem? Haben hier MS SQL-Datenbanken mit ca. 10 Mio. Datensätzen im Einsatz und Gesamtgröße von 30 GB.

Das "Problem" ist eher das die BDE teilweise bessere Defaulteinstellungen hat als wenn man so einfach die ADO-Wrapper-Komponenten von Delphi "out of the box" verwendet (Hier vor allem CursorLocation). Du hast vermutlich deine 400k Datensätze einfach versucht in einem Grid darzustellen. Da per ADO mit den Std-Einstellung eine Client-Curser verwendet wird kommmen alle Datensätze erst mal zum Client. Bei der BDE wird ein Serverseitiger Curser verwendet. Aber schon mal probiert bei der BDE dann den Cursor zum Ende der Datenmenge zu bewegen ... Von dem Sinn 400k Datensätze in einem Grid anzuzeigen ganz zu schweigen.

Wir selbst haben über die Jahre BDE durch native Zugriffskompos ersetzt, Schrittweise die letzten DB-Sensitiven Controls entfernt und auch ADOExpress eleminiert und direkt auf ADO aufsetzend (für MS SQL Server) und haben gewaltige Performancevorteile. DB's die mit dem alten System gar nicht mehr zu verwalten sind können immer noch bewältigt werden.

Zitat von hoika:

2. Cursor-Einstellungen prüfen (muss entweder auf Server oder Client gesetzt werden,
Server ist schneller)

Autsch! Serverseitige Curser sind nur bei nicht zu großen Ergebnissmengen und der Nötigkeit an eine DB-Grid zu binden schneller. Da der MS SQL-Server (bis zur 2005er-Version) kein Multiversionskonzept unterstützt muß er Temporärtabellen erzeugen. Und wenn diese nicht in den Speicher passen heißt es Swappen. Damit kannst du die Gesamtperformance sowas in den Keller fahren - und das mit einer einzigen Query. Wieso hat man wohl bei ADO.NET die Serverseitigen Curser eh komplett unterschlagen und arbeitet wenn es geht mit clientseitigen ungebundenen Dataset's?

Hallo,

meines Wissens sollten die serverseitigen Cursor aber
in der 3.0 wieder eingeführt werden ?

Ich hatte dazu nur mal was gelesen bei Access.
Du sollte man den Cursor auf Client stellen,
weil ja Server das Ado selber ist,
also die Daten doppelt vorliegen würden.

Wenn ich nen select * from bla machen
ohne where holt er sich dann nicht alle
Datensätze übers Netz bei clClient ?

Nuja, ein select * from macht man eh nicht.

Was ich eher meinte war, sowas ganz zu vermeiden.

Falls etwas mit der ganzen Tabelle gemacht werden soll,
sollte man das es in tsql machen (falls es geht).



Add:
Hier noch nen Link, ist zwar für sql7, aber ausprobieren macht schlau
http://www.aspheute.com/artikel/20001013.htm

nach cursor location suchen

Interessant ist auch Cursor type



Heiko