Multiple transactions are not supported by the database

[Oswald Mair]

Hallo Tino,

das dürfte eigentlich kein Problem sein, sofern ich dich richtig verstanden habe.

Beispiel:
User A: Öffnet das Kundenfenster und beginnt einen neuen Kunden einzutragen. Er bekommt eine neue Kundennummer -> select max (kundennummer)+1 from Kunden.

User B: Beginnt ebenfalls einen neuen Kunden einzutragen, dieser bekommt natürlich die gleiche Kundennummer weil User A noch nicht Commit aufgerufen hat.

Derjenige der zuerst speichert behält die Kundennummer, und der andere erhält die Meldung "Kundennummer vergeben" und bekommt dann die nächste freie Nummer.

Aber ich werde deinen Rat befolgen, und diese Aktionen auch mal an unterschiedlichen PC testen, man testet ja bekanntlich nie genug.

Danke
Oswald

[tinof]

Ja,

eventuell auch mal per SQL Server Managementstudio die Sperren in der Datenbank bei diesen Tests verfolgen - bevor es erst beim Kunden zu Deadlocks kommt.

Und nochwas, sorry, ich bin ein richtiger Spielverderber:

Die Kundennummer als Primärschlüssel zu verwenden ist zwar naheliegend, aber ich habe generell sehr schlechte Erfahrungen mit deratigen 'funktionalen' Primärschlüsseln gemacht.
Sauberer wäre es, eine reine EDV - Nummer zum Primärschlüssel zu machen und die Kundennummer nur als UNIQUE Index zu führen. Da kann man ganz viel dazu schreiben, und ich weiß auch nicht, wie viel du schon implementiert hast - ob ein Redesign überhaupt noch machbar ist (würde auch deinen geschilderten Lösungsansatz erschweren). Ist halt nur so eine Erfahrung von mir, die ich z. T. sehr leidvoll (und teuer) machen mußte.

Wie immer Viel Erfolg,
ein schönes 4. Adventswochenende und viele Grüße
Tino

[O. Helper]

Ich kenne Delphi nicht und arbeite (zu meine Glück) auch nicht damit.

In meinen Augen ist es einfach der falsche Weg, eine Transaction mit Beginn der Eingabe zu starten, das ist irgendwie "zweckfrei". Ein User beginnt zu tippen und alle anderen sind blockiert; bei 200 Usern und mehr eine einzige Katastrophe.

Wenn ein User einen "Hauptsatz" anlegt, wird der sofort gespeichert und committed; der ist dann eben da. War das ein vermeintliches versehen, wird der eben wieder gelöscht. Wie sollte das bei einer Web App funktionieren? Ich gebe Daten ein und klick dann auf "confirm"; aus. Ich kenne keine WebApp, die es ermöglicht, wirklich alle Eingabe einer Session rückgängig zu machen.
Andere Lösung ist eben, das der Client alle Daten zunächst sammelt und wenn alles erfasst ist, werden alle Daten auf einmal in die DB in einer Transaction in die DB geschreiben. So läuft es z.B. bei einer Bestellung in einem Web-Shop ab.

[Oswald Mair]

hallo und guten Morgen.

Tino:
jetzt habe ich einige Test durchgeführt und es sieht recht gut aus, habe es auf 4 verschiedenen PCs getestet und auf jeden PC mehrere Fenster bzw. Connections aufgemacht, und es funktioniert, nur halt mit den vielen offenen Connections was mich ehrlich gesagt ziemlich stört, aber vorrest funkt es.

Olaf:
Ich weiß das du recht hast und ich habe schon einige male daran gedacht alles umzubauen, aber das wäre ein großer Aufwand der wahrscheinlich irgendann bevorsteht ... naja ...



Aber vielleicht funktioniert das Ganze weil ich in meinen Projekt keine DBControls wie (DBEdit, DBGrid, DBCombo) verwende,
sondern ganz einfache Controls wie (TEdit, TStringGrid, TCombo) ...

wie würdest ihr beispielsweise einen Datensatz oder mehrere Datensätze aus einer TGrid zwischenspeichern?

danke Oswald

[newbie2011]

Connection Pooling verwenden