Announcement

Collapse
No announcement yet.

Problem mit dem Arbeiten einer lokal angelegter Datei ("Tabellen"-Stream) !

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem mit dem Arbeiten einer lokal angelegter Datei ("Tabellen"-Stream) !

    Hallo,<BR><BR>ich habe Probleme mit der Realisierung einer Temp-Tabelle <b>Lokal</b>.<BR><BR>Idee ist die Folgende:<BR><BR>Die Bearbeitung eines Records mit dem <b>SQL-Server 2000</b> läuft normal über <b>TDBEdit, TDBxxx ...</b> - Komponenten. Nun, für das <b>hinzufügen</b> eines neuen Records, will ich zuerst diesen <b>Lokal</b> (Stream o. ä.) durchführen und wenn dieser hinzugefügt werden soll, diesen dem SQL-Server übergeben.<BR><BR>Um dieser Vorgang, wegen verschiedenen Hilfstabellen (versch. Strukturen), offen zu halten, dachte ich an folgendes Konzept:<BR>> Ich speichere die Tabelle mit nur einem Record mittels <b>ADODataSet.SaveToFile()</b> ab, <BR>> die <b>Verbindung</b> zum SQL-Server abbrechen, <BR>> den abgespeicherten Record mit <b>ADODataSet.LoadFromFile()</b> laden, <BR>> geladenen Record leeren und als <b>"neuen Record"</b> gespeichert bereitstellen.<BR>> der Benutzer füllt diesen leeren Record mit neuen Daten und speichert ihn ab.<BR><BR>Das Problem ist nun, dass diesen geänderten Record nicht mehr gespeichert werden kann. Folgender Fehler tritt nun auf:<BR><BR><i>Fehler bei einem aus mehreren Schritten bestehenden Vorgang. Prüfen Sie die einzelnen Statuswerte. </i><BR><BR>Statuswert: <i>rsModified</i><BR><BR>Kann mir jemand einen Tipp geben, woran das liegen kann, denn beim 1. Mal klappts ja, indem ich ja den Record durch <i>Bearbeiten</i> erstmals abspeichere.<BR><BR>Einen ähnlichen Fall hatte ich auch schon. Da wurde der <b>Primary-Key</b> vergessen und folgende Einstellung (A. Kosch):<BR><BR><i>&nbsp;with ADODataSet.Recordset do begin<BR>&nbsp;&nbsp;&nbsp;Properties['Update Criteria'].Value := adCriteriaKey;<BR>&nbsp;&nbsp;&nbsp;Properties['Update Resync'].Value := adResyncAll;<BR>&nbsp;end;</i><BR><BR>Hier funktioniert dieser Ansatz, um den Fehler zu beheben, nicht !<BR><BR>MfG<BR>Adi

  • #2
    Hallo,

    diese ganze Mühe ist völlig unnötig, da ADO das automatisch im Hintergrund macht, wenn für den LockType der Wert <b>ltBatchOptimistic</b> ausgewählt wird. Bei der Suche nach der Zeichenkette "ltBatchOptimistic" lassen sich hier im FORUM weitere Hinweise finden

    Comment


    • #3
      Hallo,

      wenn im ltBatchOptimistic-Modus ein Datensatz geändert wird, erhält er das Kennzeichen für einen geänderten Datensatz, so dass ADO nur SQLs generiert, die ein UPDATE probieren. Wenn dieser "Datensatzpuffer" mutwillig mit einem neuen Datensatz überschrieben wird, ohne den internen Statuswert zu ändern, kann das nicht funktionieren, da anstelle von INSERT nur UPDATE generiert wird.

      Mit Hilfe eines Clone's kann man sich die Situation nach dem 1. Editieren einmal hinter den Kulissen anschauen:
      <pre>
      aCloneRS := ADODataSet1.Recordset.Clone(adLockUnspecified);
      // geklonte Datenmenge filtern: Nur neue/geänderte/gelöschte anzeigen
      aCloneRS.Filter := adFilterPendingRecords;
      ADODataSetClone.Recordset := aCloneRS;
      ADODataSetClone.Active := True;
      </pre&gt

      Comment

      Working...
      X