"A user transaction is already in progress."

[HeikoAdams]

Hallo,
bei unserem Kunden erscheint in unregelmäßigen Abständen die Fehlermeldung "A user transaction is already in progress." wenn ein Datensatz bearbeitet werden soll.

Wie lässt sich diese Fehlermeldung am elegantesten abfangen?

Gruß

Heiko

[mkinzler]

DBMS wechseln :mrgreen:

[hoika]

Hallo,

ist aber schon merkwürdig.
Unter Paradox gibt es gar keine Transaktionen.
Die Meldung kenne ich nur von SQL-Links, wenn die BDE auf eine SQL-DB zugreifft.

Benutzt Ihr Cached Updates ?

Um die Meldung elegant zu behebn, müsstest du erst mal wissen,
wo genau sie im Code kommt.

Zitat:

Datensatz bearbeiten

Das wäre eine Table.Edit ?

ein try except drum würde die Meldung "verschwinden lassen",
aber vielleicht kommt dann beim Table.Post die gleiche Meldung.

Du solltest mal im Netz nach "bde in a peer network" suchen,
vielleicht ist beim Kunden was falsch gesetzt ?


Und wie mkinzler schon sagte -> DBMS wechseln.

Übrigens lässt sich die BDE in einer sanften Migration auch noch mit Firebird
verwenden.


Heiko

[HeikoAdams]

Zitat:

Zitat von hoika

Benutzt Ihr Cached Updates?

Mein Vorgänger hat bei dem betreffenden Tabellenobjekt tatsächlich CachedUpdates auf True gesetzt. Macht das bei Paradox-Datenbank, die auf einem Netzwerkserver liegt, überhaupt Sinn? :wiejetzt:
Wenn ich die OH richtig verstehe, bringt das doch mehr Probleme als das nützt.

[hoika]

Hallo,

das ist alles nur ne Notlösung für das Nichtvorhandensein echter Transaktionen.
Bei cached updates werden die Änderungen in temporäeren (Pdx)-Tabellen lokal gespeichert,
und dann per ApplyUpdate koomplett rübergeschickt.

Aber eine Garantie, dass das wirklich klappt, hat man nicht.

Also wech damit (ich meinte mind. Paradox ;) ).



Heiko

[HeikoAdams]

Okay, dann werde ich CachedUpdates mal deaktivieren und schauen wo dann überall knallt 8)

[HeikoAdams]

Mit deaktiviertem CachedUpdate sinkt bei unserem Kunden die Performance des Programms ins bodenlose, so dass wir das CachedUpdate wieder aktivieren mussten. Gibt es andere Lösungsmöglichkeiten - außer Migration auf ein anderes DBMS?

[hoika]

Hallo,

hm, dann machst du was verkehrt ...

OK OK,
Cached Updates reduzieren die Netzlast, angeblich ...
weil sie ja per ApplyUpdate alle Änderungen auf einen Rutsch schreiben
(Netzwerk-Belastung).

Kannst du das Problem denn nachstellen bei Euch in der Firma ?.
Dazu muss die DB natürlich auf einen File-Server und nicht lokal sein.


Da das Problem hausgemacht ist (Paradox),
solltest du rausfinden, warum es ohne Cached Updates so langsam ist.
Ich hatte damals keine Performance-Probleme, ausser 3. (lahmer Norton lokal)

Dazu ein paar Fragen:
1. Wie wird auf die DB zugegriffen (TTable/TQuery)
2. Wie viele gleichzeitige User ?
3. Virenscanner auf dem Server und den Clients (verlangsamt jeden Zugriff) ?
4. Select * verwendet
5. DBGrid direkt zum Bearbeiten benutzt statt separater TTable
6. Wird nach ApplyUpdates noch ein DbiSaveChanges gemacht ?
7. Wie viele Daten werden geschrieben ?

und und und

Ich bin froh, dass ich mit Pdx nicht mehr so in Berührung komme ;)


Zieh dir mal hier Traffic Monitor den Traffic-Monitor, um festzustellen, wieviel MB übers Netz gehen.


Heiko

[mkinzler]

Wohl nicht. ein Tod musst du also sterben.