refresh der Daten aus einer Datenbank --- aber wo ?

[jobo]

Ich sehe die Sache auch ähnlich wie haentschman. Mit autarken Queries ist man auf der sicheren Seite, aber:

Ich habe nie Probleme mit datensensitiven Komponenten gehabt. Und ich vermute, dass die Erfahrungen von h etwas mit der DB (herstellerspezifisch) zu tun haben und mit dem damaligen Stand der Technik (dieses Herstellers).

Stichwort 1:
Locking (row level locking). Das konnte vor Jahren nicht jeder (vielleicht auch heute noch nicht). Wenn ich also einen Datensatz ändere und dabei aus Mangel an Fähigkeiten dbseitig eine ganze Page gelockt wird, ist das sch..lecht.

Stichwort 2:
Clienttransaktionen; ich habe sowas nur spaßeshalber benutzt, default und produktiv war immer autocommit ohne eine einzige Zeile/Befehl, der aktiv Transaktionen verwaltet.
M.E. liegt es in der Natur der Sache, Transaktionshandling ist Serverangelegenheit. Übernimmt man das im Client, bricht man erstens das Prinzip und ist 2. auf die Qualität der Komponentenimplementierung und 3. auf die Fähigkeiten der DB (siehe z.B. Stichwort1) angewiesen.
Beispiel: Hab gerade angefangen, einen Datensatz zu ändern und mein Programm schmiert ab. Die DB hat nun ein Lock vom Client da rumfliegen, das garantiert nie ordentlich aufgelöst wird..

Stichwort 3:
Ressourcenverbrauch / konkurriende Zugriffe: Gewisse Hersteller von RDBMS waren nie dafür berühmt, dass sie es gut können. Darauf basiert m.E. eine ganze Technologie bei denen. Je weniger meine DB kann, desto mehr muss ich sie schonen. Also bitte nur mal kurz Daten lesen oder updaten und dann wieder verschwinden. Dieses Prinzip ist zwar nicht unmodern, in mehrschichtigen Anwendungen ganz normal, bei bestimmten Anbietern hatte ich aber immer das "Gefühl", sie können es gar nicht viel besser.

Das nur mal so wild in Kürze.

Fazit: setzt man tatsächlich moderne RDBMS ein, kann man sehr wohl mit diesen Verfahren arbeiten. Ich gehe mal davon aus, dass viele DB Hersteller in den letzten 15 Jahren an ihrer Technik gearbeitet haben. Rowlevellocking und andere tolle Sachen sollten mittlerweile unproblematisch (vorhanden) sein. Letztlich kann ich also mit dem datensensitiven Komponenten (Delphikomponenten oder auch Third Party) robuste Anwendungen in kurzer Zeit entwickeln, also das machen, womit Delphi mal "berühmt" wurde.

[nahpets]

ADO und aktuallisierbare Querys geht im Prinzip aber:

Je nach Datenbank unterschiedlich und nicht immer zwingend "fehlerfrei".

Was eventuell helfen könnte ist:

Die ADO-Querys haben u. a. die Eigenschaft CursorLocation und die Eigenschaft CursorType .

Denen kann man beiden unterschiedliche Werte in unterschiedlichen Kombinationen zuweisen.

Hier hilft es eventuell mal auszuprobieren, was bei der aktuellen Datenbank die "richtige" Kombination ist. Bei Access ist es (soweit ich mich erinnere)

Delphi-Quellcode:

Query.CursorLocation := clUseServer;
Query.CursorType := ctStatic;

Diese Kombination ist aber (aus meiner Erinnerung) bei FireBird kontraproduktiv.

Wird zusätzlich noch 'ne ADOConnection genutzt, so bei der auch mal mit den Eigenschaften CursorLocation und IsolationLevel rumspielen.

Hier mal ein unrepräääsäääännnntatieeefes, abschrääääckendes Speibiel aus meinem Sourcenfundus, um eben genau das hier aktuell diskutierte Problem (halbwegs) zu umgehen:

Delphi-Quellcode:

  // Hier den Datenbanktypen abfragen und die Werte für Cursor ... setzen.
  // CursorLocation bei SQLite muss wohl clUseClient sein,
  // bei Access aber clUseServer
  // Hier noch testen, was bei SQLite am sinnvollsten ist.
  if fDBIsSQLite then begin
    // ctUnspecified, ctOpenForwardOnly, ctKeyset, ctDynamic, ctStatic
    // Diese Variante spart Arbeitsspeicher und ist schnell.
    // Aber es gibt keine RecNo.
    // Änderungen von Datensätzen nicht möglich.
    // con.CursorLocation    := clUseServer;  // Dann gibt es keine RecNo :-(
    // qrySQL.CursorType     := ctKeyset;
    // qrySQL.CursorType     := ctStatic;
    // Benötigt viel Arbeitsspeicher, deutlich mehr, als die Datenbankgröße.
    // Ist sehr langsam.
    qrySQL.CursorLocation := clUseClient;
    qrySQL.CursorType     := ctDynamic;
    // qrySQL.CursorType     := ctStatic;
    // qrySQL.CursorType     := ctKeyset;
    // dbckOK ist 'ne TDBCheckBox
    dbckOK.ValueChecked   := 'T';
    dbckOK.ValueUnchecked := 'F';
  end else
  if fDBIsAccess then begin
    qrySQL.CursorLocation := clUseServer;
    qrySQL.CursorType     := ctStatic;
    dbckOK.ValueChecked   := 'Wahr';
    dbckOK.ValueUnchecked := 'Falsch';
  end else
  if fDBIsPostGres then begin
    // Programmhänger beim Speichern neuer Datensätze.
    qrySQL.CursorLocation := clUseClient;
    qrySQL.CursorType     := ctDynamic;
    // Programmhänger beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseClient;
    // qrySQL.CursorType     := ctStatic;
    // Programmhänger beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseClient;
    // qrySQL.CursorType     := ctKeyset;
    // Programmhänger beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseClient;
    // qrySQL.CursorType     := ctUnspecified;
    // beendet den Datenbankprozess von PostGres beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseServer;
    // qrySQL.CursorType     := ctDynamic;
    // beendet den Datenbankprozess von PostGres beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseServer;
    // qrySQL.CursorType     := ctStatic;
    // beendet den Datenbankprozess von PostGres beim Speichern neuer Datensätze.
    // qrySQL.CursorLocation := clUseServer;
    // qrySQL.CursorType     := ctKeyset;
    // Läßt bereits das Lesen von Datensätzen nicht zu.
    // qrySQL.CursorLocation := clUseServer;
    // qrySQL.CursorType     := ctUnspecified;
    dbckOK.ValueChecked   := 't';
    dbckOK.ValueUnchecked := 'f';
  end else
  if fDBIsFirebird then begin
    qryMaxTextverwaltungID.SQL.Text := 'SELECT GEN_ID(gen_TextverwaltungID,1) FROM RDB$DATABASE';
    qrySQL.CursorLocation := clUseClient;
    qrySQL.CursorType     := ctDynamic;
    dbckOK.ValueChecked   := '1';
    dbckOK.ValueUnchecked := '0';
  end else begin
    // Ansonsten?
    qrySQL.CursorLocation := clUseClient;
    qrySQL.CursorType     := ctDynamic;
    dbckOK.ValueChecked   := '1';
    dbckOK.ValueUnchecked := '0';
  end;
  qryMaxTextverwaltungID.CursorLocation := qrySQL.CursorLocation;
  qryMaxTextverwaltungID.CursorType     := qrySQL.CursorType;
  qryExecSQL.CursorLocation             := qrySQL.CursorLocation;
  qryExecSQL.CursorType                 := qrySQL.CursorType;
  // Diese Kombination scheint bei FireBird und TAdoTable zu funktionieren.
  // Nein, nicht wirklich.
  // Bei einem Refresh gibt es eine Fehlermeldung.
  if fDBIsFirebird then begin
    if not tbTextVergleich.Active then begin
      tbTextVergleich.CursorLocation        := clUseClient;
      tbTextVergleich.CursorType            := ctUnspecified;
    end;
    if not tbTextVerwaltung.Active then begin
      tbTextVerwaltung.CursorLocation       := clUseClient;
      tbTextVerwaltung.CursorType           := ctUnspecified;
    end;
  end else begin
    if not tbTextVergleich.Active then begin
      tbTextVergleich.CursorLocation        := qrySQL.CursorLocation;
      tbTextVergleich.CursorType            := qrySQL.CursorType;
    end;
    if not tbTextVerwaltung.Active then begin
      tbTextVerwaltung.CursorLocation       := qrySQL.CursorLocation;
      tbTextVerwaltung.CursorType           := qrySQL.CursorType;
    end;
  end;

[jobo]

Zitat von nahpets:

ADO und aktuallisierbare Querys geht im Prinzip aber:

Je nach Datenbank unterschiedlich und nicht immer zwingend "fehlerfrei".

Das sollte m.E. primär durch die Natur der Query und des zugrundeliegenden Datenmodells vorgegeben sein.

4. simple (mindest-)Voraussetzungen:
Ein Primärschlüssel (Der Primärschlüssel der aktuellen Datenmenge) sollte enthalten sein.
Der Primärschlüssel sollte je Datensatz eindeutig sein.
Es darf keine Aggregatfunktion in der Abfrage enthalten sein.
"Virtuelle Spalten" dürfen nicht geändert werden (Funktionen, Nachschlagewerte, ..)

Im Zweifel ein Update der Abfrage "zu Fuß" gegen den Server testen, also außerhalb des Programms. Die DB sagt dann, ob sie das kann bzw. wenn sie es nicht kann. Geht es nicht, hat man idR aber eher einen konzeptionellen Fehler in der Datenmenge/dem Vorgang.

Das Problem hier war aber ja wohl nicht so sehr das Update selbst, sondern die Aktualisierung der Datenanzeige. Ggf. empfiehlt sich die Arbeit mit Bookmarks. Zu Beitrag #3. Die Fehlermeldung zeigt ja kein Access Violation, sondern lediglich eine Ausnahmemeldung. Notfalls sollte wie schon vorgeschlagen das Schließen und Öffnen helfen. Nach dem Öffnen muss der fragliche Datensatz dann per Code wieder lokalisiert werden.