Entwickler-Ecke
Datenbanken - Datensatz kann nicht gesperrt ...anderen BENUTZER ? HÄ?
Karstadt - Mi 02.11.05 13:15
Titel: Datensatz kann nicht gesperrt ...anderen BENUTZER ? HÄ?
Hallo. Ab und zu kommt es bei mir zu diese Fehler:
DS kann nicht geändert werden, da der DS von einen anderen Benutzer geändert wurde.
Wie kann das passieren?
noidic - Mi 02.11.05 13:19
Wo und wann kommt der Fehler?
Karstadt - Mi 02.11.05 13:34
Bei der Funktion "Edit" (nicht regelmäßig)
noidic - Mi 02.11.05 13:40
Dann wird wohl zwischenzeitlich ein anderer Benutzer ( oder auch eine andere Abfrage o.ä. von dir ) den Datensatz modifiziert haben.
jasocul - Mi 02.11.05 13:42
Dann liegt wohl noch eine Sperre auf dem Datensatz.
Warst du im Edit und das Programm ist abgebrochen? Oder du brichst es innerhlab von Delphi ab.
Arbeitest du mit mehreren Personen oder Anwendungen auf dem Datensatz? Dann ist die Meldung einwandfrei.
Karstadt - Mi 02.11.05 13:48
Hallo. Diese Anwendung befindet sich in der Entwicklung. Ich arbeite alleine mit diese Anwendung.
Als ich während meine Ausbildung mit DBF gearbeitet habe, habe ich einen datensatz mit LOCK gesperrt und mit UNLOCK entsperrt. Hier in SQL kommt es garnicht vor
noidic - Mi 02.11.05 13:59
Auf eigentlich allen Datenbanksystemen wird ein Datensatz gesperrt, wenn er bearbeitet wird. Allerdings auch erst in dem Moment, wo die Bearbeitung beginnt, nicht schon bei der Selektierung des DS. Entsperrt wird nach Eintrag der Änderung ( also beim Post ).
Außerdem wird die Bearbeitung eines selektierten DS dan nnicht zugelassen, wenn zwischen der Selektion und der Bearbeitung der Datensatz verändert worden ist. Um das zu verhindern, kann man normalerweise bereits beim select den Datensatz als 'zu ändern' markieren und damit sperren ( in oracle z.B. mit select... for update, bei andern Systemen weiss ichs nicht ).
In deinem Fall kanns zwei Möglichkeiten geben:
- Dein Programm ist kurz voher zwischen Edit und Post abgeraucht. Dann ist der Datensatz noch gesperrt.
- Zwischen dem Select und dem Edit gibts von anderer Stelle ein Update auf den Datensatz.
Mehr Möglichkeiten fallen mir im Moment nicht ein, aber das sind ja schon mal 2 :)
jasocul - Mi 02.11.05 14:14
 Karstadt hat folgendes geschrieben: |
Hallo. Diese Anwendung befindet sich in der Entwicklung. Ich arbeite alleine mit diese Anwendung.
Als ich während meine Ausbildung mit DBF gearbeitet habe, habe ich einen datensatz mit LOCK gesperrt und mit UNLOCK entsperrt. Hier in SQL kommt es garnicht vor |
Dann lies doch meine ersten beiden Möglichkeiten nochmal durch.
Noch ein paar Fachinformationen: SQL ist keine Datenbank, sondern eine Abfragesprache für Datenbanken. dBase (DBF) als Datenbank zu bezeichnen ist imho übertrieben. Vielleicht sind meine Erwartungen auch zu hoch. :wink: Wie die Locks auf einer richtigen DB funktionieren (können; es gibt noch andere Methoden, aber das würde jetzt zu weit führen), hat
noidic ja schon erläutert.
Karstadt - Mi 02.11.05 15:07
journal := TQuery
t_journal := TTABle
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:
|
s_journal.Open;
s_journal.First;
for i := 1 to 16 do
begin
JournalID := s_journal.FieldByName('Jour_ID').AsString;
t_journal.Locate('Jour_ID', JournalID, [loCaseInsensitive]);
t_journal.Edit;
IF TPanel(FindComponent('Panel'+IntToStr(i))).Color = clRed Then
begin
t_journal.FieldValues['Status'] := 'Offen';
t_journal.FieldValues['Auftragsart'] := f_reklamation_auswahl.Caption;
end
else t_journal.FieldValues['Status'] := 'fertig';
<span style="font-weight: bold">t_journal.Post;</span> t_journal.Last;
s_journal.Next;
end; |
noidic - Mi 02.11.05 15:11
Soweit ich das durchschaue siehts soweit gut aus. Bleibt noch die sache mit dem abgeschmierten Programm.
Was mir auch noch einfällt ist, dass einige DB-Oberflächen wie TOAD ( in einigen Versionen ) und ähnliche den aktuell ausgewählten Datensatz auch einfach mal sperren. Könnte es sowas sein?
jasocul - Mi 02.11.05 15:19
Sieht theoretisch richtig aus. Die andere Möglichkeit hat
noidic ja noch genannt.
Eine Möglichkeit, wenn auch unwahrscheinlich:
Du arbeitest mit FieldValues. diese Eigenschaft arbeitet mit Variant. Abgesehen davon, dass das langsam ist (Nimm doch FieldByName), kommt die DB vtl. nicht einwandfrei damit zurecht. Aber wie gesagt, ich halte das für eher unwahrscheinlich. Einen Test wäre es aber wert.
Karstadt - Mi 02.11.05 15:39
Danke. werde ich versuchen. Das dumme an der Sache ist, mal kommt es, mal nicht...
Karstadt - Mi 02.11.05 16:17
mir ist aufgefallen, das die Funktion t_journal.recno mir immer den Wert -1 gibt. Ist das normal ?
Stefan.Buchholtz - Mi 02.11.05 16:22
| Karstadt hat folgendes geschrieben: |
| mir ist aufgefallen, das die Funktion t_journal.recno mir immer den Wert -1 gibt. Ist das normal ? |
Das ist bei SQL-Datenbanken normal. RecNo funktioniert bei der BDE nur bei lokalen Tabellen (Paradox, DBase).
Stefan
Karstadt - Fr 04.11.05 10:07
Vielleicht liegt das daran, das ich pararell eine ander Anwendung laufen lasse, die beim beenden die Tabelle nicht schließt. Tabelle.close.
Kann das auch sein? Bis jetzt war ich immer der meinung, das beim beenden die Tabellen automatisch beenden werden.
MFG
noidic - Fr 04.11.05 10:25
Das kann sehr gut sein. Zwar wird der Cursor irgendwann dichtgemacht, dass kann aber auch mal ne Weile dauern.
Jeden Cursor, den man öffnet, sollte man auch, direkt wenn man ihn nicht mehr braucht, wieder schließen.
OlliWausD - Fr 04.11.05 13:59
| Karstadt hat folgendes geschrieben: |
Vielleicht liegt das daran, das ich pararell eine ander Anwendung laufen lasse, die beim beenden die Tabelle nicht schließt. Tabelle.close.
Kann das auch sein? Bis jetzt war ich immer der meinung, das beim beenden die Tabellen automatisch beenden werden.
MFG |
beim beenden von was?? wenn du ein 2. Prog offen hast, wo du z.B.: im form4 auf die daten zugreiffst, jedoch die z.B.: Table nicht deaktivierst und dieses Formular schließt, is die Table noch offen, da sie erst beim form4.free aufgelöst wird.
kommt halt drauf an, wie du deine Forms erstellst (beim Prog-start oder manuell)
mfg
OlliW
Karstadt - Di 08.11.05 14:43
Genau so funktioniert das. Die Deklaration von Formularen geschieht automatisch und nicht manuell. (das ist ein Projekt, denn ich weiter entwicklere, eine Änderung am kompletten Projekt ist "sehr schwer", da die Folgen fatal sein könnten.
PS: Kann das daran liegen, das die Datenbank am Server liegt? MFG
Karstadt - Di 08.11.05 16:02
Hier. Passiert das, un zwar nur ein mal: (beim ersten mal!)
t_rabatt.FieldByName('status').asString := FloatToStr(Offen);
t_rabatt.Post;
Karstadt - Fr 11.11.05 11:20
Hallo. Nun habe ich das Problem gelöst.
IF not (Trim(t_journal.Fieldbyname('Auftragsart').asstring) = Trim(f_reklamation_auswahl.Caption)) Then
begin
t_journal.Edit;
t_journal.Fieldbyname('Auftragsart').asstring := f_reklamation_auswahl.Caption;
t_journal.Post;
end;
Nun fuktioniert es. Diese Fehlermeldung kamm nur dann, wenn ich eine Datensatz zum ändern aufrufe und mit Fieldbyname gleiche werte zuweise die der DS schon hat. Das führ zu diesen Fehler.
Ist das normal?
MFG
noidic - Fr 11.11.05 11:29
Nein, das ist nicht normal.
Karstadt - Fr 11.11.05 12:30
Hallo. Kann das bitte jemand ausprobieren:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
| With Table1 do
begin
edit;
Fieldbyname('Status').AsString :='fertig';
post;
end; |
Mehrmals ausführen.
Beim zweiten mal kommt es immer zu der obengennanten fehler.
Meine DB ist die MYSQL
Dieses mal habe ich eine NEUE Anwendung ausprobiert mit eine einzige Table kopmponente.
Ich vermute die MYSQL DB ist falsch eingestellt, bwz ist fehlerhaft.
Moderiert von raziel: Delphi-Tags hinzugefügt.
cyberax - Di 16.05.06 15:55
Hallo,
das Thema hier ist schon alt aber da ich gerade (wiedermal) das selbe Problem haben wollte ich nur fragen, ob du es nun lösen konntest?!?
Auch bei mir kommt dieser Fehler. Ich arbeite auch mit mysql. Und zum Probieren habe ich auch eine kleine Procedur geschrieben, die einfach nur ein Feld ändern und sofort wieder speichert und trotzdem der Fehler.
Keine Ahnung was das soll??
Mfg Daniel
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!