Hallöchen Ich greife von meinem Delphiprogramm mittels ADO und SQL auf eine Access Datenbank zu. Das schreiben eines Datensatzes dauert ca. 0,15sec. In der Accessdatenbank befinden sich gerade mal 3 Datensätze. Ein Datensatz besteht aus ca. 50 Feldern. Warum dauert dies solange ? Ist das normal ? Wie ginges es schneller. Ich muss des öfteren mehrere Datensätze lesen, ändern und wieder schreiben. Der Benutzer der Software soll aber nicht zu lange warten müssen. Vielen Dank für Eure Hilfen. hmg Mandi
Gast
#1308666
ich würde ne richtige datenbank nehmen (mysql, postgresql, mssqql) und nicht über ADO sonder über ODBC gehen, ist zwar umständlicher aber wesentlich schneller. Ist es bei dir wirklich die einfüge zeit oder auch die Zeit zum öffnen der datenbank?
Gast
#1308677
Die gleiche Konstellation kommt bei mir zwar auch öfters vor, aber ich kann nicht behaupten, dass die Kombination Delphi - ADO - Jet Engine so langsam wäre. Bei 0,15s kann irgend etwas nicht stimmen. Dauern 2 aufeinanderfolgende Datensätze dann 0,30s? Wenn ja, muss man vermutlich am Code was ändern. Wenn nein, dauert nur das erste Öffnen der Connection und das Anmelden so lange.
Hallo Edi. Hier ein Codebeispiele wie ich es mache : s := 'UPDATE Pumpendaten SET Name1 = Wert1 , Name2 = Wert2 ....... s := s + '" WHERE LaufendeNummer = ' + IntToStr(Index); ADOQuery1.SQL.Clear; ADOQuery1.SQL.Add(WideString(s)); ADOQuery1.ExecSQL; Ich habe keine Ahnung, ich kann mit aber schon vorstellen, dass dabei jedesmal eine neue Verbindung zur Datenbank aufgebaut werden muss und dass dies natürlich dauert. Wie kann ich es machen die Verbindung aufzubauen, alle Änderungen durchzuführen und dann die Verbindung wieder zu schliessen. Vielen Dank für Eure Hilfe. hmg Mandi
Gast
#1309134
eventuell sollte du ein paar Randbedingungen noch erwähnen. Wieviele Indexe sind auf der Tabelle, Wieviele Daten sind schon drin, Wie schnell ist der Rechner (bei einem 386 sind 0,15s schon sehr gut)
Gast
#1309138
Liegt auf LaufendeNummer ein Index?
Hi Manfred, mit Delphi über ADO auf Access zugreifen und das noch über SQL ist immer mit Problemen behaftet. Access kann kein SQL, sämtliche SQL Befehle werden nur simuliert und intern übersetzt und ausgeführt. Probleme Access - ADO >> Stichwort : Cachingverhalten von Access Sicherlich hängt die Ausführung vom Rechner, der DB-Struktur (Index, etc ) und ... noch ab. Ich nutze Absolute Database und bin zufrieden. kleiner Tipp : wenn du die Felder pro Datensatz verringern kannst wird es auch schneller, prüf mal ein DB Aufbau. Gruß Andreas
Gast
#1312708
>mit Delphi über ADO auf Access zugreifen und das noch über SQL ist immer >mit Problemen behaftet. Kühne Behauptung. Ich mach das seit Jahren, es gab nie Probleme. >Access kann kein SQL, sämtliche SQL Befehle >werden nur simuliert und intern übersetzt und ausgeführt. Ich glaube, ich muss alles neu lernen :-) @ Manfred Schön (mandinice): Sorry dass ich mir mit der Antwort Zeit gelassen habe, ich war unterwegs. Du hast doch sicher irgendwo einen Connection String. Gibst Du den im TADOQuery an, oder hast Du eine TADOConnection? Bei mir läuft das immer so: Ich lege eine TADOConnection (ADOConnection1) auf die Form. Bei allen ADOQuerys, also ggf. auch auf anderen Forms, setze ich die Eigenschaft "Connection" auf "ADOConnection1" (bzw - wenn die ADOQuery auf einer anderen Form ist, auf "Form1.ADOConnection1"). In den ADOQuerys bleibt die Eigenschaft "ConnectionString" leer, nur bei ADOConnection1 steht der richtige Connection String in der Eigenschaft "ConnectionString". Jetzt setze ich In der ADOConnection1 noch die Eigenschaft "LoginPrompt" auf false (weil mich das nervt und weil ich das üblicherweise nicht brauche). Alles andere läuft wie gehabt. Der Vorteil ist, dass nur einmal eine Verbindung aufgebaut wird, sobald das erste mal von einer ADOQuery ein SQL-String gesendet wird. Anschließend bleibt die Verbindung bestehen, bis das Programm beendet wird oder bis Du "ADOConnection1.Connected := false" sagst. Allen anderen Aussagen zum Trotz: Mit Delphi über ADO per SQL auf eine Access-Datenbank geht völlig problemlos. Selbstverständlich gibt es auch andere Lösungen, und vielleicht sind sie sogar besser, aber das heißt nicht, dass diese Lösung nicht funktioniert.
Hallo Edi Danke. Ich denke den Tip habe ich gebraucht. hmg Mandi