2 Benutzer ändern einen Datensatz (SQL Server 7)

[Hermann Schmidt]

Hi,<br>
<p>
Umfeld: Delphi 5 C/S mit Updatepack1, ADO mit Updatepack1, MS-SQL Server 7, MDAC 2.5<br>
<p>
Ich verwende TADOQuery, mit Cursorlocation=clUseClient und SQLOLEDB für die ADOConnection. Die verwendete Tabelle hat einen Primärindex, der auf Clientseite (GUID) generiert wird.<br>
Folgendes Szenario:<br>
Benutzer1 versetzt einen Datensatz in den edit-Modus. Benutzer2 tut das anschliessend mit dem gleichen Datensatz ebenfalls. Beide nehmen Änderungen vor. Benutzer1 speichert den Datensatz. Anschliessend möchte Benutzer2 speichern und bekommt die Fehlermeldung:<br>
<b>Row cannot be located for updating. Some values may have been changed since it was last read.</b><br>
Bis hierhin ist ja alles noch verständlich. Jetzt versucht Benutzer2 mit Cancel aus dem bearbeiteten Datensatz herauszukommen und damit beginnen die 'Merkwürdigkeiten'. Er bekommt obige Fehlermeldung noch einmal zu sehen, die ADOQuery geht in den Browsemodus (wie gewünscht) und die DBGrid (dxDBGrid), die die Tabelle anzeigt, enthält nur noch den <b>einen</b> (soeben) bearbeiteten Datensatz.<br>
Hat vielleicht jemand eine Idee, wie man diese Erscheinung umgehen könnte?<br>
Ich danke schonmal für Hinweise.<br>
Hermann

[Andreas Kosch]

Hallo,

warum wird TADOQuery verwendet? Wenn ich die dafür besser geeignete Komponente <b>TADODataSet</b> verwende, gibt es an dieser Stelle keine Probleme

[Hermann Schmidt]

Hallo Herr Kosch,<br>
inwiefern ist TADODataSet besser geeignet ?<br>
Herman

[Andreas Kosch]

Hallo,

im Kleingedruckten von ADO Express ist zu lesen, dass <b>TADOTable</b> und <b>TADOQuery</b> nur als Kompatibilitäts-Komponenten für den erleichterten Umstieg von einer BDE- zu einer ADO-Anwendung vorgesehen sind. Dabei bedeutet Kompatibilität sowohl eine Funktionseinschränkung als auch ein anderes Verhalten im Vergleich zu <b>TADODataSet</b>. Nur TADODataSet setzt direkt auf das COM-Objekt <i>RecordSet</i> auf und kann die Funktionen von Tabellen, SELECT-Abfragen und Aufrufen von Stored Procedures abwickeln.

Ich würde daher nur für simpleste Anwendungen auf TADOTable zurückreifen (wenn überhaupt, denn der Aufwand ist mit TADODataSet nicht höher).

Außerdem spielt bei ADO die Konfiguration eine deutliche höhere Rolle als bei der BDE. Über <b>CursorLocation</b> und <b>CursorType</b> erhält man zum Beispiel beim Wechsel auf einen anderen Wert in Abhängigkeit vom verwendeten OLE DB-Provider ein völlig anderes Verhalten. Erschwerdend kommt hinzu, dass im Objektinspektor nur die allgemeingültigen Eigenschaften sichtbar sind. Jeder OLE DB-Provider bringt seine "eigenen" Einstellungsmöglichkeiten mit, der nur zur Laufzeit im eigenen Sourcecode gesetzt werden können. Man muss sich angewöhnen, in der Dokumentation des verwendeten OLE DB-Providers (<i>Microsoft MDAC SDK</i> oder <i>Microsoft Platform SDK</i>) nachzulesen, in welchem Fall welche Einstellung geeignet ist (oder alternativ und zeitaufwendig in "Versuch-und-Irrtum"-Experimenten die Erfahrungen selber sammeln).

&#10

[Hermann Schmidt]

Hallo,<br>
vielen Dank für die Kommentare. Ich verstehe die Problematik. Aber leider ist die Erscheinung mit TADODataset die gleiche.<br>
Muss dann wohl doch am OLE DB-Provider liegen.<br>
Viele Grüsse<br>
Herman

[BlueBit]

Hallo Herman,

ja habe auch einige Probleme, aber nicht mit ADO, sondern mit ADO Express. Kollege Kosch (gruß an unseren Ober-Guro Andy Koschy) hat Recht, wenn er auf das SDK verweist. Es lohnt sich dort mal reinzuschauen. Ich ging an die ADO - Geschichte als verwöhnter Delphi-Anwender, ein paar Eigenschaften setzen und schon läuft alles. So einfach ist es leider doch nicht. Aber mit Hilfe des SDK's bekommt man eigentlich fast alles hin. Verwende die Dynamic Properties, das ist mit das wichtigste. Dieses sollte man auf jeden Fall beherrschen. Sie ändern sich leider von Provider zu Provider, aber mit ihnen kann man viele Probleme lösen.

Achso.. jetzt bin ich wieder vom Thema abgekommen, wollte Dir doch ein paar Tipps geben. Wenn es beim Post Probleme gibt, nutzt der Anwender oder Du die Cancel Methode. Soweit alles in Ordnung. Aber auch beim Cancel können Fehler auftreten, wenn das passiert, dann verwende bitte die Methode CancelUpdates von TAdoDataSet. Du verwendest das dxDbGrid, gute Entscheidung . Dann noch ein FullRefresh für Dein tateloses dxDbGrid, dann sollte alles gut laufen.

Bis dann
Mathia

[Hermann Schmidt]

Hallo Mathias,<br>
vielen Dank erstmal für die Tipps. Ich probier das mal aus.<br>
Es ist schon möglich, dass die dxDBGrid daran schuld ist, dass
nur ein Datensatz nach dem gescheiterten Post und dem anschliessenden Cancel angezeigt wird. Das würde die ganze
Problematik etwas schwieriger machen. Die Ursache tritt in TADODataset
bzw. meinem Nachfahren auf (wo man diese Klippe umschiffen könnte), die Auswirkung zeigt sich in der Grid. Ich melde mich noch mal, wenn
ich was brauchbares gefunden habe.<br>
Viele Grüsse, Herman

[Stefan Glock]

Nur am Rande.

Es gibt keine besseren Grids als die von DevExpress :-

[BlueBit]

Hallo,

find ich auch, Ihr müsst euch unbedingt mal die Neuen Edit Componenten von DevExpress anschauen, einfach Super

<pre>
Bis dann
Mathias
</pre&gt

[Hermann Schmidt]

Hallo zusammen,<br>
an der dxDBGrid liegt die oben beschriebene Erscheinung definitiv nicht. Ich habe immer noch keine Lösung gefunden. Vielleicht gibt es
ja doch noch jemanden, der mit diesem Problem schon mal konfrontiert war.<br>
Viele Grüsse<br>
Herman

[Hermann Schmidt]

Hallo,<br>
ich habe soeben die Lösung gefunden: Klappt ein Post nicht, werden nach einem anschliessenden Cancel nur noch die (der) Konfliktdatensätze angezeigt. Mit einem expliziten CancelUpdates werden alle anstehenden Updates verworfen und wieder alle Datensätze
(wie vor dem Edit) angezeigt.<br>
Viele Grüsse<br>
Herman