Datensatz Sperre MySQL

[KlausV]

Hallo Zusammen,
ich finde einfach den Fehler nicht, weil manchmal funktioniert es und manchmal nicht.
Fehlermeldung: "Datensatz kann nicht geändert werden, da der Datensatz von einem anderen Benutzer gesperrt wurde"

MySQL Zugriff erfolgt über ODBC.

Ich habe ein Grid. In diesem Grid werden Datensätze angezeigt. Es gibt eine Checkbbox im Grid, die offen für die Verwaltung ist. Die zugehörige TQUERY Komponente hat die Eigenschaft RequestLive TRUE. Dadurch kann ich direkt im Grid in die Datenbank schreiben. Nun hake ich den ersten Satz an, das funktioniert und dann den zweiten und dann kommt die Fehlermeldung, aber nicht immer. Mir ist dabei aufgefallen, dass nach dem ersten click noch keine Änderung in der DB vollzuogen ist, erst beim 2. click, der aber ja nicht funktioniert, weil die Fehlermeldung kommt.

Ich weiß, dass es ab und an Probleme mit mysql gibt, aber wie kann man das lösen.

Danke schon mal.

Gruß Klaus

[TigerLilly]

Bist du sicher, dass die Meldung so lautet?

Zitat:

Zitat von KlausV (Beitrag 1515873)

Fehlermeldung: "Datensatz kann nicht geändert werden, da der Datensatz von einem anderen Benutzer gesperrt wurde"

[KlausV]

Ja, sicher.

[jobo]

1. diese Version von mySQL ist uralt. Warum quält man sich mit sowas?
2. Deinen Angaben kann man nicht entnehmen, welche storage engine verwendet wird. Diese dürfte aber wichtig sein, um das Sperrverhalten zu beurteilen.
3. Einfache (ältere oder schlechte) Systeme sperren nicht gezielt Datensätze, sondern ganze Blöcke. Es würde dazu passen, dass der Effekt nicht immer auftritt, nur wenn beide DS im gleichen Block liegen.
4. Der Code zum Speichern kann natürlich auch problematisch sein, ist aber nicht aufgeführt.

[KlausV]

Zitat:

Zitat von jobo (Beitrag 1515907)

1. diese Version von mySQL ist uralt. Warum quält man sich mit sowas?
2. Deinen Angaben kann man nicht entnehmen, welche storage engine verwendet wird. Diese dürfte aber wichtig sein, um das Sperrverhalten zu beurteilen.
3. Einfache (ältere oder schlechte) Systeme sperren nicht gezielt Datensätze, sondern ganze Blöcke. Es würde dazu passen, dass der Effekt nicht immer auftritt, nur wenn beide DS im gleichen Block liegen.
4. Der Code zum Speichern kann natürlich auch problematisch sein, ist aber nicht aufgeführt.

Ja, das stimmt leider, die mysql ist uralt und danke für die Infos.

Ich vermute, dass es an diesem RequestLive = True liegt. Werde mir etwas anderes überlegen.

[KlausV]

Ich habe noch nicht die Lösung gepostet, sorry.
Es lag nicht an RequestLive = True sondern am UpdateMode. Dieser ist auf upWhereKeyOnly zu stellen, dann funktioniert es. Ich habe aber keine Ahnung, wieso es bis vor kurzen noch funktioniert hat. Vielleicht hat jemand noch eine passende Idee?
Was ich herausgefunden habe, der Mode upWhereKeyOnly geht mit Sperren anders um, d.h. benutzen zwei user den gleichen record, dann bekommt der eine User keine Meldung, dass der Satz gesperrt ist. Ergo, müsste es doch irgendwelche Sperren geben in den internas von mysql. Ein reboot bringt vermutlich auch nichts. Wo könnte ich noch schauen. Ein SHOW OPEN TABLES zeigt mir auch keine Sperren.

[TigerLilly]

Seltsam.

upWhereKeyOnly und seine Varianten steuern nur, wie die WHERE Klausel im Update-Statement erstellt wird. Einmal eben nur die PKs oder nur über die geänderten Feldwerte etc. Wenn das Update sich auf keinen Datessatz auswirkt wird ein Fehler geworfen.

Da ist die Fehlermeldung irreführend und müsste heißen: "Datensatz kann nicht geändert werden, da der Datensatz von einem anderen Benutzer GEÄNDERT wurde". Oder wie es auf Englisch heißt "Couldn't perform the edit because another user changed the record"

Und: Das ist alles Clientseitig + da sind keine Sperren vom Server im Spiel.

[KlausV]

Ich verstehe nur nicht, wieso sich Delphi oder mysql so verhält. Vor einem Monat konnten wir noch ganz normal die Daten ändern.
Hat jemand noch einen Tipp bezüglich mysql? Irgendwo muss sich ja etwas verändert haben. Den gleichen Satz, den ich mit dem Delphi Programm nicht ändern kann, kann ich unter SQL update direkt ändern.
Einen SHOW OPEN TABLES zeigt mir keine Sperren, ebenso kann ich nichts verdächtiges feststellen, wenn ich show engine innodb status starte.
Falls es sich nicht löst, dann werde ich den Mode auf upWhereKeyOnly ändern.
Ich befürchte halt nur, dass es nach und nach auch andere Tabellen betrifft.
Hier der Auszug aus show engine...


mysql> show engine innodb status;
+--------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Type | Name | Status |
+--------+------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| InnoDB | |
=====================================
230506 10:50:37 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 25 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 1 1_second, 1 sleeps, 0 10_second, 1 background, 1 flush
srv_master_thread log flush and writes: 1
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 2, signal count 2
Mutex spin waits 2, rounds 2, OS waits 0
RW-shared spins 2, rounds 60, OS waits 2
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 1.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter 254F00
Purge done for trx's n:o < 2546E8 undo n:o < 0
History list length 2341
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 19, OS thread handle 0x7fb4a886b700, query id 3 localhost root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
454 OS file reads, 3 OS file writes, 3 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276671, node heap has 2 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 355538308
Log flushed up to 355538308
Last checkpoint at 355538308
0 pending log writes, 0 pending chkp writes
8 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 52320
Buffer pool size 8191
Free buffers 7746
Database pages 443
Old database pages 0
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 443, created 0, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 443, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2883, id 140413891512064, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

[Delphi.Narium]

Wenn ich das recht verstanden habe, bedeutet die Fehlermeldung, dass (mindestens) zwei Änderungen an dem gleichen Datensatz durchgeführt werden soll(t)en. Wenn es eine Sperre gibt, so kann es sich hierbei um einen Vorgang von Millisekunden handeln. Wenn Du also die Fehlermeldung bekommst und in der DB nachschaust, kann die Sperre schon längst wieder aufgehoben sein. Die Chance die konkrete Sperre zu "sehen" tendiert daher zuweilen gegen 0.

Andererseits: Wenn alle Felder beim Update geprüft werden, kann diese Fehlermeldung auch auftreten. Das beutet aber nicht, dass es tatsächlich eine Sperre gibt, sondern nur: Der Datensatz ist in der DB jetzt anders als er zum Zeitpunkt, zu dem die Daten gelesen wurden, anders war. So 'ne richtige Sperre liegt da nicht vor, sondern eine Fehlermeldung, die textlich eher irreführend sein könnte.

Ursache ist in der Regel, dass tatsächlich der bereffende Datensatz geändert wurde.

In Deinem Szenario kannst Du aber auch selbst der sperrende User sein.
Es wird im Grid was geändert. Was ich nicht weiß und das Du mal prüfen solltest: Wird nur der gerade geänderte Datenatz in Richtung DB geschickt oder eventuell alle im Grid angezeigten Sätze? Hierdurch könnten eventuell Inkonsistenzen zwischen den Daten im Grid und der DB entstehen. Wäre zwar extrem unangenehm (und sicherlich in Richtung (gravierender) Bug einzuordnen), aber absolut ausschließen würd' ich das erstmal nicht.

Versuchter Workaround: Wenn im Grid ein Satz geändert wurde: Nach dem Post ein Query.Refresh einbauen, so dass die Daten neu aus der DB gelesen werden. Ist performenstechnisch sicherlich suboptimal, aber um zu prüfen, ob der Fehler dann weg ist, sicherlich erstmal geeignet. Wird der Fehler so behoben, kannst Du dann zumindest etwas gezielter weiter nach der eigentlichen Ursache suchen.

Gibt es auf der Datenbank irgendwelche Trigger, die ggfls. für veränderte Daten zuständig sein könnten, aber nicht grundsätzlich Daten ändern, sondern nur unter bestimmten Bedingungen, so dass der Fehler nicht immer auftreten muss?

Bei dem Klick im Grid wird die Änderung (vermutlich) nicht sofort Richtung Datenbank geschickt, sondern erst, wenn Post aufgerufen wird. Das passiert, wenn man z. B. in 'nem DBNavigator den entsprechenden Button drückt oder wenn man den Datensatz wechselt.
Kannst Du sowas in Deinem Programm mal machen?
Erst Checkbox klicken, dann explizit ein Post aufrufen, dann den Datensatz wechseln und dann die zweite Checkbox klicken? Tritt der Fehler dann immernoch (sporadisch) auf?

[TigerLilly]

Siehe hier:
https://docwiki.embarcadero.com/RADS...es_Are_Applied

UpdateMode steuert, wie die WHERE Klausel des Update-Statements erzeugt wird. Wenn das Updatestatement keine Sätzte ändert, wird diese Fehlermeldung ausgegeben (weil Daten zwischenzeitlich geändert). Die Änderung kann unbeabsichtigt auch von dir herbeigeführt worden sein. TRIGGER wie Delphi.Narium schreibt, oder Runden von Floats uvm. Und klar dass bei UpdateKeyOnly der Fehgler nicht mehr kommt, weil viele Feldinhalte da von der prüfung ausgenommen sind.

Sieh dir die SQL Update Statements im Profiler oder trace an und beachte die WHERE Klausel.

[Delphi.Narium]

upWhereKeyOnly hat den Vorteil, dass Fehler nur bei (durch andere User verursachte) Änderungen an Schlüsselwerten auftreten. Hat den Nachteil, dass bei unveränderten Schlüsseln ggfls. zwischenzeitlich durchgeführte Änderungen an Nichtschlüsselwerten gnadenlos überschrieben werden.

Die Frage ist also: Was will man hier genau erreichen?

Vor dem Speichern eine absolut exakte Prüfung auf Änderungen oder reicht es, wenn man "den richtigen Datensatz erwischt". Frei nach dem Motto: Die letzte Änderung gewinnt?

[TigerLilly]

UpdateKeyOnly wird in der Regel auch viel schneller sein, weil es da Indices drauf gibt, andernfalls hast du im WHERE ja Felder, die uU einen FullTableScan erfordern. Aber das ist jetzt ein anderes Thema.

[KlausV]

Zitat:

Zitat von Delphi.Narium (Beitrag 1522155)

Wenn ich das recht verstanden habe, bedeutet die Fehlermeldung, dass (mindestens) zwei Änderungen an dem gleichen Datensatz durchgeführt werden soll(t)en. Wenn es eine Sperre gibt, so kann es sich hierbei um einen Vorgang von Millisekunden handeln. Wenn Du also die Fehlermeldung bekommst und in der DB nachschaust, kann die Sperre schon längst wieder aufgehoben sein. Die Chance die konkrete Sperre zu "sehen" tendiert daher zuweilen gegen 0.

Andererseits: Wenn alle Felder beim Update geprüft werden, kann diese Fehlermeldung auch auftreten. Das beutet aber nicht, dass es tatsächlich eine Sperre gibt, sondern nur: Der Datensatz ist in der DB jetzt anders als er zum Zeitpunkt, zu dem die Daten gelesen wurden, anders war. So 'ne richtige Sperre liegt da nicht vor, sondern eine Fehlermeldung, die textlich eher irreführend sein könnte.

Ursache ist in der Regel, dass tatsächlich der bereffende Datensatz geändert wurde.

In Deinem Szenario kannst Du aber auch selbst der sperrende User sein.
Es wird im Grid was geändert. Was ich nicht weiß und das Du mal prüfen solltest: Wird nur der gerade geänderte Datenatz in Richtung DB geschickt oder eventuell alle im Grid angezeigten Sätze? Hierdurch könnten eventuell Inkonsistenzen zwischen den Daten im Grid und der DB entstehen. Wäre zwar extrem unangenehm (und sicherlich in Richtung (gravierender) Bug einzuordnen), aber absolut ausschließen würd' ich das erstmal nicht.

Versuchter Workaround: Wenn im Grid ein Satz geändert wurde: Nach dem Post ein Query.Refresh einbauen, so dass die Daten neu aus der DB gelesen werden. Ist performenstechnisch sicherlich suboptimal, aber um zu prüfen, ob der Fehler dann weg ist, sicherlich erstmal geeignet. Wird der Fehler so behoben, kannst Du dann zumindest etwas gezielter weiter nach der eigentlichen Ursache suchen.

Gibt es auf der Datenbank irgendwelche Trigger, die ggfls. für veränderte Daten zuständig sein könnten, aber nicht grundsätzlich Daten ändern, sondern nur unter bestimmten Bedingungen, so dass der Fehler nicht immer auftreten muss?

Bei dem Klick im Grid wird die Änderung (vermutlich) nicht sofort Richtung Datenbank geschickt, sondern erst, wenn Post aufgerufen wird. Das passiert, wenn man z. B. in 'nem DBNavigator den entsprechenden Button drückt oder wenn man den Datensatz wechselt.
Kannst Du sowas in Deinem Programm mal machen?
Erst Checkbox klicken, dann explizit ein Post aufrufen, dann den Datensatz wechseln und dann die zweite Checkbox klicken? Tritt der Fehler dann immernoch (sporadisch) auf?

Ich versuche es mal zu erklären, hoffe aber, dass ich es einigermaßen brauchbar wiedergeben kann. Ist leider schon lange her, wo ich mit Delphi zu tun hatte.
Das Problem tritt nicht bei einem Grid auf, sondern im Einzelbild der Verwaltung. Sprich es gibt ein Grid und mit doppelklick gelange ich auf das Einzelbild. Verändere ich dort meine Werte und drücke auf speichern, tritt der Fehler auf. Auf dem Screen ist ein ganz normales TQUERY Objekt benutzt (RequestLive=ON). Der Fehler tritt im BeforePost event auf.
Andere Frage: Welchen profiler kann ich installieren? Bitte den link dazu, wenn möglich.
Danke.
Klaus

[TigerLilly]

https://www.google.com/search?client...+trace+queries

[Delphi.Narium]

Zitat:

Zitat von KlausV (Beitrag 1522173)

Ich versuche es mal zu erklären, hoffe aber, dass ich es einigermaßen brauchbar wiedergeben kann. Ist leider schon lange her, wo ich mit Delphi zu tun hatte.
Das Problem tritt nicht bei einem Grid auf, sondern im Einzelbild der Verwaltung. Sprich es gibt ein Grid und mit doppelklick gelange ich auf das Einzelbild. Verändere ich dort meine Werte und drücke auf speichern, tritt der Fehler auf. Auf dem Screen ist ein ganz normales TQUERY Objekt benutzt (RequestLive=ON). Der Fehler tritt im BeforePost event auf.
Andere Frage: Welchen profiler kann ich installieren? Bitte den link dazu, wenn möglich.
Danke.
Klaus

Das widerspricht aber deutlich der Beschreibung aus dem Eingangspost:

Zitat:

Zitat von KlausV

Ich habe ein Grid. In diesem Grid werden Datensätze angezeigt. Es gibt eine Checkbbox im Grid, die offen für die Verwaltung ist. Die zugehörige TQUERY Komponente hat die Eigenschaft RequestLive TRUE. Dadurch kann ich direkt im Grid in die Datenbank schreiben. Nun hake ich den ersten Satz an, das funktioniert und dann den zweiten und dann kommt die Fehlermeldung, aber nicht immer. Mir ist dabei aufgefallen, dass nach dem ersten click noch keine Änderung in der DB vollzuogen ist, erst beim 2. click, der aber ja nicht funktioniert, weil die Fehlermeldung kommt.

Um was für ein Grid handelt es sich?

Ein DBGrid? Da kann ein Doppelklick durchaus zu einer Veränderung führen (z. B. bei 'ner CheckBox im DBGrid), wenn auch unbeabsichtigt. Und das kann zu dem von Dir genannten Problem führen, muss aber nicht.

[KlausV]

Zitat:

Zitat von Delphi.Narium (Beitrag 1522175)

Zitat:

Zitat von KlausV (Beitrag 1522173)

Ich versuche es mal zu erklären, hoffe aber, dass ich es einigermaßen brauchbar wiedergeben kann. Ist leider schon lange her, wo ich mit Delphi zu tun hatte.
Das Problem tritt nicht bei einem Grid auf, sondern im Einzelbild der Verwaltung. Sprich es gibt ein Grid und mit doppelklick gelange ich auf das Einzelbild. Verändere ich dort meine Werte und drücke auf speichern, tritt der Fehler auf. Auf dem Screen ist ein ganz normales TQUERY Objekt benutzt (RequestLive=ON). Der Fehler tritt im BeforePost event auf.
Andere Frage: Welchen profiler kann ich installieren? Bitte den link dazu, wenn möglich.
Danke.
Klaus

Das widerspricht aber deutlich der Beschreibung aus dem Eingangspost:

Zitat:

Zitat von KlausV

Ich habe ein Grid. In diesem Grid werden Datensätze angezeigt. Es gibt eine Checkbbox im Grid, die offen für die Verwaltung ist. Die zugehörige TQUERY Komponente hat die Eigenschaft RequestLive TRUE. Dadurch kann ich direkt im Grid in die Datenbank schreiben. Nun hake ich den ersten Satz an, das funktioniert und dann den zweiten und dann kommt die Fehlermeldung, aber nicht immer. Mir ist dabei aufgefallen, dass nach dem ersten click noch keine Änderung in der DB vollzuogen ist, erst beim 2. click, der aber ja nicht funktioniert, weil die Fehlermeldung kommt.

Um was für ein Grid handelt es sich?

Ein DBGrid? Da kann ein Doppelklick durchaus zu einer Veränderung führen (z. B. bei 'ner CheckBox im DBGrid), wenn auch unbeabsichtigt. Und das kann zu dem von Dir genannten Problem führen, muss aber nicht.

Sorry, die Situation zwischen dem Eingangsfehler und der jetzigen Situation ist eine andere (wie beschrieben zuvor). Den Eingangsfehler habe ich durch den UpdateMode gelöst. Ich möchte aber nicht, in allen Queries den UpdateMode verändern, kann ja auch irgendwie nicht sein. Die Fehlermeldung ist die selbe. Ja, es ist ein dbGRID.
Ich verstehe immer noch nicht, wieso es bis vor wenigen Wochen funktioniert hat.

[KlausV]

Zitat:

Zitat von TigerLilly (Beitrag 1522174)

https://www.google.com/search?client...+trace+queries

In meinte den Profiler! Was wird da installiert?

[Delphi.Narium]

Zitat:

Zitat von KlausV (Beitrag 1522176)

Ich verstehe immer noch nicht, wieso es bis vor wenigen Wochen funktioniert hat.

Es wurde halt irgendwas verändert, das muss weder auf der Datenbank noch in Deinem Programm der Fall sein.

Du programmierst mit Delphi 7, so wie es in Deinem Profil steht?

TQuery lässt auf einen Zugriff über die BDE schließen, die ist jetzt nicht mehr unbedingt das Neueste vom Neuesten, oder eher absolut veraltet (und das sagt jetzt einer, der nur mit Delphi 7 programmiert ;-)).

Irgendeine Änderung am Betriebssystem, so dass z. B. das Doppelklickverhalten verändert wurde. Eventuell wird ja ein Doppelklick im DBGrid, bei 'ner Checkbox, ..., nun wie zwei einzelne Klicks verarbeitet, was dann ggfls. zu zwei sehr kurz hineinander durchgeführten Änderungen führen, die aber im Konflikt zueinander stehen. Änderungen an der Konfiguration des ODBC-Treibers, Änderungen an der Konfiguration der BDE, ...

Wegen Problemen mit der BDE bin ich längst auf die ADO-Komponenten umgestiegen (bzw. die ZeosLib). Die ADO-Komponenten können direkt auf den ODBC-Treiber zugreifen, die Zwischenschicht der BDE kann also ersatzlos entfallen. Der Umbauaufwand dürfte sich in Grenzen halten, könnte sogar kürzer sein, als der Aufwand, den Du bis jetzt schon in die Fehlersuche und Fehlerbehebung gesteckt hast.

Der Fehler liegt aber (mit an Sicherheit grenzender Wahrscheinlichkeit) nicht auf der Datenbankseite.

[TigerLilly]

Zitat:

Zitat von Delphi.Narium (Beitrag 1522178)

Es wurde halt irgendwas verändert, das muss weder auf der Datenbank noch in Deinem Programm der Fall sein.

Ja, das kann auch mit den Daten zu tun haben. Eben zb Floats, die durch Rundung beim Schreiben andere Werte als beim Lesen enthalten.

Schau dir die SQL Statements der UPDATEs an und dort die WHERE Klausel bei UpdateWhereChanged, dann weißt du in 1 Minute was los ist.

[KlausV]

Zitat:

Zitat von TigerLilly (Beitrag 1522196)

Zitat:

Zitat von Delphi.Narium (Beitrag 1522178)

Es wurde halt irgendwas verändert, das muss weder auf der Datenbank noch in Deinem Programm der Fall sein.

Ja, das kann auch mit den Daten zu tun haben. Eben zb Floats, die durch Rundung beim Schreiben andere Werte als beim Lesen enthalten.

Schau dir die SQL Statements der UPDATEs an und dort die WHERE Klausel bei UpdateWhereChanged, dann weißt du in 1 Minute was los ist.

Das kann ich nicht, weil es kein direktes SQL Statement gibt. Es wird über RequestLive alles gehandelt. Wir kommen wieder zurück zum Ursprung, ich muss wissen, welche SQL's delphi intern absetzt.

[TigerLilly]

Ja, eben, du musst dir die SQL Statements ansehen, die Delphi zusammenbaut. Und dazu musst du mySQL Server einen Trace mitlaufen lassen. Bzw kannst du dich wenn ich das richtig im Kopf habe auch in das Tdatabase oder Tconnection Objekt reinhängen, aber das habe ich jetzt nicht im Kopf. Ich habe mir das immer direkt am Server unabhöängig von Delphi angesehen.