Datensatzsperre

Hallo zusammen,

ich habe eine fachspezifische Lösung, die über die Borland
Datenbankengine und ODBC-Treiber auf MySQL- und Informix-Datenbanken
arbeitet. Nun wurden die Daten eines Kunden von Informix nach MySQL
portiert - Konsolenausgabe aus Informix, Syntaxanpassung, Import mit
phpAdmin..

Die Daten liegen in folgenden Umgebungen/Systemen vor:

MySQL 4.1. auf Fedora 4
MySQL 4.05 auf XP
2 unterschiedliche ODB-Treiber

Die Datenbank besteht aus Haupt- und Untertabellen. Wenn ich nun in
Untertabellen (nicht in allen) die übernommenen Daten bearbeiten will,
bekomme ich beim Abspeichern die Fehlermeldung "Datensatz kann nicht
gesperrt werden, da der Datensatz von einen anderen Benutzter geändert
wurde". Neue Datensätze dagegen kann ich anlegen und problemlos
ändern.

Das Frontend setzt explizit keine Sperren. Wenn ich eine Untertabelle
durch die eines anderen Kunden testweise ersetze, kann ich ALLE
Datensätze ändern, der Fehler tritt nicht mehr auf, unabhängig von der
MySQL-Serverversion.

Ich habe mittlerweile keinen blassen Schimmer, wo ich noch nachschauen
sollte, die Datenbank wurde nun mehrfach geleert, gefüllt, neu
angelegt usw., immer das gleiche Ergebnis, Unterschiede zu
Untertabellen anderer Kunden sind nicht festzustellen usw.

Ich bin für jeden Hinweis dankbar.
Jürgen

Re: Datensatzsperre

js schrieb:
> Hallo zusammen,
>
> ich habe eine fachspezifische Lösung, die über die Borland
> Datenbankengine und ODBC-Treiber auf MySQL- und Informix-Datenbanken
> arbeitet. Nun wurden die Daten eines Kunden von Informix nach MySQL
> portiert - Konsolenausgabe aus Informix, Syntaxanpassung, Import mit
> phpAdmin..
>
> Die Daten liegen in folgenden Umgebungen/Systemen vor:
>
> MySQL 4.1. auf Fedora 4
> MySQL 4.05 auf XP
> 2 unterschiedliche ODB-Treiber
>
> Die Datenbank besteht aus Haupt- und Untertabellen. Wenn ich nun in
> Untertabellen (nicht in allen) die übernommenen Daten bearbeiten will,
> bekomme ich beim Abspeichern die Fehlermeldung "Datensatz kann nicht
> gesperrt werden, da der Datensatz von einen anderen Benutzter geändert
> wurde".

Wörtlich? Dann würde ich mal außerhalb von MySQL z.B. mit strings
suchen, wo diese Fehlermeldung erzeugt wird. Denn mW gibt MySQL nur
englischsprachige Fehler aus.

Wenn Du aber sicher bist, dass es sich um einen MySQL-Fehlermeldung
handelt, dann solltest Du die per Cut&Paste hier abladen, und
vielleicht auchmal versuchen, das Verhalten auf der Kommandozeile von
MySQL zu reproduzieren.

Re: Datensatzsperre

js wrote:

> ich habe eine fachspezifische Lösung, die über die Borland
> Datenbankengine und ODBC-Treiber auf MySQL- und Informix-Datenbanken
> arbeitet.



> Die Datenbank besteht aus Haupt- und Untertabellen.

Was immer du mit "Untertabellen" meinst.

> Wenn ich nun in
> Untertabellen (nicht in allen) die übernommenen Daten bearbeiten will,
> bekomme ich beim Abspeichern die Fehlermeldung "Datensatz kann nicht
> gesperrt werden, da der Datensatz von einen anderen Benutzter geändert
> wurde". Neue Datensätze dagegen kann ich anlegen und problemlos
> ändern.

Das ist keine MySQL-Meldung. Es wäre hilfreich zu wissen, was *genau*
die Applikation denn macht, wenn sie Datensätze sperrt. Mit SQL-Level
LOCKs hat das (hoffentlich) nichts zu tun. Eher tippe ich auf ein Flag
oder Timestamp im fraglichen Datensatz.

> Das Frontend setzt explizit keine Sperren. Wenn ich eine Untertabelle
> durch die eines anderen Kunden testweise ersetze, kann ich ALLE
> Datensätze ändern, der Fehler tritt nicht mehr auf, unabhängig von der
> MySQL-Serverversion.

Dann glaube ich auch nicht mehr, daß es generell an MySQL liegt. Eher
sind die Tabellen dieses einen Kunden irgendwie speziell. Kannst du die
Daten applikationsseitig migrieren? Also die Applikation an Informix
ihre Daten entladen lassen, dann an MySQL hängen und die Daten wieder
laden? Und waren die Daten in Informix auch sauber abgeschlossen, als
du exportiert hast? Vielleicht waren ja die Locks beim Export gesetzt.

> Ich habe mittlerweile keinen blassen Schimmer, wo ich noch nachschauen
> sollte, die Datenbank wurde nun mehrfach geleert, gefüllt, neu
> angelegt usw., immer das gleiche Ergebnis

Der Windows-Weg (Reboot macht alles gut) hilft nur bei Windows. Bevor
du Maßnahmen ergreifst, solltest du erstmal das Problem identifizieren.
Für eine Ferndiagnose sind die Informationen zu dürftig.


XL

Re: Datensatzsperre

Das Problem steckte in den Daten bzw. der Tabellendefinition. Die
Datumsfelder in den betroffenen Untertabellen waren mit

date default NULL

definiert, während durch den Dump die Einträge auf "0000-00-00"
lauteten, wenn kein Datum definiert war.

Warum das zu der Fehlermeldung "Datensatz kann nicht
gesperrt werden, da der Datensatz von einen anderen Benutzter geändert
wurde" kann ich nicht nachvollziehen, jedenfalls hat mich das in die
Irre geführt.

Nachdem ich alle Einträge von "0000-00-00" auf NULL gesetzt habe,
können nun alle Datensätze bearbeitet werden.

Vielen Dank für euren Einsatz!
Jürgen

On Fri, 23 Jun 2006 10:49:34 +0200, Axel Schwenke
wrote:

>js wrote:
>
>> ich habe eine fachspezifische Lösung, die über die Borland
>> Datenbankengine und ODBC-Treiber auf MySQL- und Informix-Datenbanken
>> arbeitet.
>
>
>
>> Die Datenbank besteht aus Haupt- und Untertabellen.
>
>Was immer du mit "Untertabellen" meinst.
>
>> Wenn ich nun in
>> Untertabellen (nicht in allen) die übernommenen Daten bearbeiten will,
>> bekomme ich beim Abspeichern die Fehlermeldung "Datensatz kann nicht
>> gesperrt werden, da der Datensatz von einen anderen Benutzter geändert
>> wurde". Neue Datensätze dagegen kann ich anlegen und problemlos
>> ändern.
>
>Das ist keine MySQL-Meldung. Es wäre hilfreich zu wissen, was *genau*
>die Applikation denn macht, wenn sie Datensätze sperrt. Mit SQL-Level
>LOCKs hat das (hoffentlich) nichts zu tun. Eher tippe ich auf ein Flag
>oder Timestamp im fraglichen Datensatz.
>
>> Das Frontend setzt explizit keine Sperren. Wenn ich eine Untertabelle
>> durch die eines anderen Kunden testweise ersetze, kann ich ALLE
>> Datensätze ändern, der Fehler tritt nicht mehr auf, unabhängig von der
>> MySQL-Serverversion.
>
>Dann glaube ich auch nicht mehr, daß es generell an MySQL liegt. Eher
>sind die Tabellen dieses einen Kunden irgendwie speziell. Kannst du die
>Daten applikationsseitig migrieren? Also die Applikation an Informix
>ihre Daten entladen lassen, dann an MySQL hängen und die Daten wieder
>laden? Und waren die Daten in Informix auch sauber abgeschlossen, als
>du exportiert hast? Vielleicht waren ja die Locks beim Export gesetzt.
>
>> Ich habe mittlerweile keinen blassen Schimmer, wo ich noch nachschauen
>> sollte, die Datenbank wurde nun mehrfach geleert, gefüllt, neu
>> angelegt usw., immer das gleiche Ergebnis
>
>Der Windows-Weg (Reboot macht alles gut) hilft nur bei Windows. Bevor
>du Maßnahmen ergreifst, solltest du erstmal das Problem identifizieren.
>Für eine Ferndiagnose sind die Informationen zu dürftig.
>
>
>XL