Entwickler-Ecke
Datenbanken - AdoCommand.Execute--> Warten bis DB aktualisiert wurde.
vladi - Mi 23.04.08 12:39
Titel: AdoCommand.Execute--> Warten bis DB aktualisiert wurde.
Hallo Leute,
Eins sage ich gleich vorne weg damit es keine Missverständnisse gibt. Ich habe diese Frage bereits in einem anderen Forum gepostet doch leider kamen wir da nicht auf eine Lösung. Vielleicht kann mir jemand von euch weiterhelfen!?
Ok hier der Link damit ihr auf dem neusten Stand seit :
http://forum.delphi-treff.de/showthread.php?t=23399
Ich danke euch im Voraus für eure Bemühungen
Greez and Thx Vladi
little-wolf - Mi 23.04.08 12:49
Titel: commit?
hallo
mal ne ganz "scheue" frage:
hast du mal versucht mit transaktionen zu arbeiten oder im sql-statement (welches mit ExecSQL ausgeführt wird) einfach am ende noch ein commit; hinzugefügt?
sobald dein veränderter datenbestand durch commit auf die db geschrieben wurde, sollte der veränderte "neue" datenbestand ja eigentlich anderswo verfügbar sein.
gruss
little-wolf
vladi - Mi 23.04.08 12:54
Ooo das ging aber schnell.
Mit Transaktionen habe ich es versucht. Kein Erfolg.
Commit das kenne ich nicht. Das ist leider erst mein 2tes Delphiprojekt.
little-wolf - Mi 23.04.08 13:07
habe grade noch nen kollegen gefragt.
kommt glaub etwas auf die db drauf an, ob es ne acces db ist oder ne anywhere oder ne oracle...
je nachdem geht das mit dem commti etwas anders... bzw. der befehl etc. wird anders genannt...
so wie er das noch aus dem kopf wusste kann man das bei acces-dbs mit "begin tran tf1" oder "begin trans tf1" (wobei tf1 der name der transaktion ist) und "commit tran tf1" oder "commit trans tf1" bzw. "rollback ...", wenns nicht geklappt hat, machen.
kann sonnst am nachmittag mal noch genauer schauen...
gruss
little-wolf
vladi - Mi 23.04.08 13:12
Es is ne Access-DB.
Ich denke das Problem liegt darin, dass die Datenbank zu "langsam" ist. Also nicht genung schnell aktualisiert.
Das wird aber durch eine Transaktion auch nicht geändert.
Oder irre ich mich?
Ich hab mir überlegt ob ich möglicherweise in Access etwas ändern muss!?
edit: das wäre super wenn du mein prob noch etwas genauer unter die Lupe nehmen köntest... Danke dir
Agawain - Mi 23.04.08 13:15
Hi
hab kein ADO, deswegen kann ich nicht nachschauen, aber schau mal, ob es im Objektinspektor, vermutlich beim Dataset, irgendwo caching-Options aktiviert sind.
vladi - Mi 23.04.08 13:18
@Agawain: Da gibts nichts in der Richtung... Nur ein Prepared... Das hat aber keinen Einfluss
alzaimar - Mi 23.04.08 13:54
Ich habe das eben mal ausprobiert. Natürlich funktioniert es so, wie es sein sollte.
vladi, erstelle bitte eine test-MDB und ein mini-Projekt, in dem das Problem auftritt. Denn nachvollziehen kann ich das nicht.
Im Anhang eine Demo, die zeigt, das man kein Sleep benötigt. Hast Du denn ein Connection-Objekt das von allen ADO-Teilen verwendet wird, oder für jede ADOQuery, ADOCommand etc. einen eigenen Connectionstring?
little-wolf - Mi 23.04.08 14:01
Titel: TADOConnection
noch ne kurze frage dazu
arbeitest du auch mit einem TADOConnection worüber die verbindung hergestellt und von den ADO-Queries genutzt wird oder trägst du die Verbindung auf jedem ADO query erneut ein?
bei uns im prog is an einer zentralen stelle ein TADOConnection für die Verbindung zuständig. Über dieses TADOConnection machen wir auch die BeginTrans / CommitTrans bzw. RollbackTrans etc.
EDIT: oops, da hatte wol jemand gerade den gleichen Gedankengang und den schnelleren post :-)
vladi - Mi 23.04.08 15:18
also ich trage beim query und beim command den gleichen connectionstring
Delphi-Quelltext
1: 2: 3:
| Form1.ADOQuery.ConnectionString := con_str; Form1.ADOCommand1.ConnectionString := con_str; Form2.ADOCommand2.ConnectionString := con_str; |
Delphi-Quelltext
1: 2:
| con_str := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + Edit3.Text + ';Mode=ReadWrite;Persist Security Info=False'; |
In dieser Prozedur wird der Insert ausgeführt. Ebenfalls wird die Prozedur "dicke_füllen" ausgeführt.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33:
| procedure TForm2.Button2Click(Sender: TObject); var dicke_insert: string; i: Double; begin try begin i := StrToFloat(Edit2.Text); if i <= 0 then ShowMessage('Ihre Einabe ist ungültig!') else begin dicke_insert := 'INSERT INTO WerkstoffDickeKomb(WerkstoffOID, Dicke)' + 'VALUES('+ WOID_new + ', ' + Edit2.Text + ')';
Form2.ADOCommand2.CommandText := dicke_insert; Form2.ADOCommand2.Execute; Screen.Cursor := crSQLWait; dicke_fuellen; Screen.Cursor := crDefault; ShowMessage('Dicke wurde erfasst!'); edit2.Text := ''; Form2.Close; end; end; except On EConvertError do ShowMessage('Ihre Einabe ist ungültig!'); On EOleException do ShowMessage('Dicke wurde bereits erfasst!'); end;
end; |
und der Select der Prozedur "dick_füllen" liest den Datensatz den in der vorhergehenden Prozedur in die DB geschrieben wurde nicht aus. Nur mit einem sleep(5000) wird der Datensatz gefunden. Alle anderen Datensätze werden korrekt ausgelesen.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25:
| procedure TForm2.FormShow(Sender: TObject); begin Edit1.Text := Form1.Werkstoff_new.Text; end;
procedure dicke_fuellen; var dicke_qry: string; begin dicke_qry := 'SELECT Dicke FROM WerkstoffDickeKomb WHERE WerkstoffOID = ' + WOID_new; Form1.ADOQuery.Close; Form1.ADOQuery.SQL.Text := dicke_qry; Form1.ADOQuery.Open; Form1.dicke.Items.Clear; with Form1.ADOQuery do begin First; while not EOF do begin Form1.dicke.Items.Add(FindField('Dicke').AsString); Next; end; end; end; |
Ich hoffe ich habe das jetzt einigermassen verständlich ausgedrükt.. :oops:
Die Tabelle in die ich den Datensatz schreibe (werkstoffdickekomb) ist ausserdem ziemlich gross. Möglicherweise ist die Verzögerung beim Insert darauf zurückzuführen.
Moderiert von
Klabautermann: Code- durch Delphi-Tags ersetzt
alzaimar - Mi 23.04.08 15:21
ERsetze mal das dreimalige Setzen des ConnectionStrings durch die Einführung einer TADOConnection und dreimaliges Setzen der 'Connection'-Eigenschaft. Dort scheint ein Problem mit den Caches der einzelnen ADO-Verbindungen zu bestehen.
Schau Dir mal mein Beispiel an: Ich verwende grundsätzlich nur eine einzige TADOConnection...
vladi - Mi 23.04.08 15:30
Hmm...
Von wo hat dan Der ADOCommand resp. das ADOQuery den Connectionstring?
Ich erhalte einen Fehler das bei ADOQuery der Connectionstring fehlt :(
little-wolf - Mi 23.04.08 15:43
vladi hat folgendes geschrieben: |
Hmm...
Von wo hat dan Der ADOCommand resp. das ADOQuery den Connectionstring?
Ich erhalte einen Fehler das bei ADOQuery der Connectionstring fehlt :( |
das is ja das gute an der TADOConnection komponente.
du brauchst lediglich bei dieser komponente den connectionstring einzufügen
und "connectiondefname" zu setzen.
dann brauchst du nur noch mit
INSTANZvonTADOQUERY.ConnectionDefName := INSTANZvonTADOConnection.ConnectionDefName
bei allen TADOQueries den ConnectionDefName setzen.
vor dem öffnen der queries natürlich auf dem TADOConnection noch Connecten...
vladi - Mi 23.04.08 15:53
Sry aber ich raff das nicht :(
was ist ein ConnectionDefName?
vladi - Mi 23.04.08 16:01
AAaaaaaa ich habs... 8)
Es funktioniert tatsächlich... Juhuu...
Ich danke euch für eure Mühe :D
Agawain - Mi 23.04.08 16:08
hi nochmal,
aber das mit den 3 Connections zeigt Dir auch gleich, was im konkurrenten Zugriff passiert.
Access ist eben keine Client-Server DB, sondern eine Desktop-Datenbank.
Wenn bei Euch nur einer Daten ändert, oder hinzufügt, bzw. löscht, ist das ok, wenn mehrere zugreifen, wirds mit Access problematisch.
Irgendwie mußt Du dann der Jet-Engine das Cachen abgewöhnen.
Ich weiss nicht, ob Access das unterstützt, aber Du könntest den Lockmodus mal auf pessimistisch stellen und die CursorLocation auf clServer.
Wie Du das Verhalten der Jetengine testen kannst, weisst Du ja jetzt auch :mrgreen:
vladi - Mi 23.04.08 16:21
Da eh nur einer an dieser DB rumwerkelt ist das ja eigentlich wurscht^^
Danke nochmal, dass ihr euch zeit genommen habt :)
greez and thx
Vladi
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!