Aktuelle Datenmenge bei SQL-Update und 2 Tquerys

[Stephan Weiser]

Ich habe eine Anwendung in der ich 2 TQuery parallel verwende:
Ein fuer normale "select ... from" und die andere um mit SQL Update-Funktionen durchzuführen.

Wenn ich jetzt mit TQuery2 ein Update durchführe wird dies in der
"select"-Query1 erst wirksam, wenn ich TQuery1 schließe und dann wieder
öffne. Dabei wird der Cursor aber immer auf den ersten Satz positioniert,
ausserdem dauert das mir zu lange.
Tquery1.refresh ist absolut wirkungslos :-( Wie kann ich Query1 dazu
bringen die von query2 geänderten Daten anzuzeigen ?

[Stefan Heitsiek]

Hallo Stephan,

ich kenne die Anwendung zwar nicht genau, aber kannst Du die Anwendung nicht so umschreiben, dass Du die TQuery1 nicht benötigst? So wie ich TUpdateSQL verstehe ist die Komponente doch genau dafür vorgesehen, dass SQL-Abfragen, die womöglich mit mehr als einer Tabellen arbeiten, updatefähig sind.

Auf Anhieb fällt mir nämlich auch keine Lösung ein.

Stefa

[Stephan Weiser]

Ja nun, ich habe ein DBGrid mit variabler Sortierung. Da kann ich
mit BoundedComponents nichts editieren (Schreibschutz).
Also nehme ich den Satz in ein Fensterchen, setze den Update-Befehl
und - fertig , NUR im DBGrid bleiben die alten Daten bis ich
die Query.close und query.open aufrufe :-

[Andreas Kosch]

Hallo,

>NUR im DBGrid bleiben die alten Daten bis ich die Query.close und query.open aufrufe

so sind die Regeln, wenn mit den BDE-Komponenten gearbeitet wird.

Eine SELECT-Abfrage fordert eine Ergebnismenge (Kopie der Daten) von der Datenbank ab, die (falls SQL-Server) zum Zeitpunkt des Starts der eigenen Transaktion gültig war. Das TDBGrid zeigt somit Daten an, die als Kopie auf dem Client-Rechner vorgehalten werden. Die über eine 2. TQuery-Instanz abgeschickte UPDATE-Anweisung ändert die Daten jedoch im Original, aber niemals in dieser Kopie. Um aktuelle Daten anzeigen zu können, muss sich das Programm ein neue Kopie holen, was typischerweise durch das Schließen und erneute Öffnen erfolgt.

Je nach verwendetem Zugriffsweg (ADO, IBObjects etc.) gibt es zwar Alternativen (um nur einen einzelnen Datensatz in dieser Ergebnismenge auffrischen zu können), aber dies hängt vom konkreten Einzelfall ab

[Stephan Weiser]

Hallo Herr Kosch,

nein, nicht nur im DBGrid, auch bei den normalen Datenbankkomponenten
DBedit oder DBText werden die Änderungen NICHT angezeigt.
Es ist sogar so, dass ich mit einem fieldbyname aus Q1 NACH
dem Update auf Q2 kein zufriedenstellendes Ergebnis erhalte.
Ich setze mit Update das aktuelle Datum. Trotz refresh
führt fieldbyname('datum').Asstring zu dem Ergebnis '' !
Ich arbeite übringens (noch) mit Paradox, die Migration auf (vorhandene) Oracle7-Datenbank soll in 6 Wochen erfolgen.

MFG

Stephan Weise

[Andreas Kosch]

Hallo,

>Es ist sogar so, dass ich mit einem fieldbyname aus Q1 NACH dem Update auf Q2 kein zufriedenstellendes Ergebnis erhalte

die Daten der Ergebnismenge werden nur von der TQuery-Instanz im lokalen Arbeitsspeicher verwaltet. Es spielt <b>keine</b> Rolle, <b>welche</b> Komponenten via TDataSource da drangehängt werden. Sowohl TDBEdit als auch TDBGrid speichern keine Daten, sondern sind nur für die Anzeige in der Benutzeroberfläche zuständig.

Da FieldByName auch nur die <b>lokale Kopie</b> der Ergebnismenge der SELECT-Abfrage auswertet, muss daher die über die andere TQuery-Instanz vorgenommen Aktualisierung solange unsichtbar bleiben, bis die TQuery-Instanz durch das erneute Ausführen der SELECT-Anweisung eine <b>frische Kopie</b> (inklusive der in der Zwischenzeit vorgenommenen Änderungen) abholt.

Wesentlich ist, dass TQuery <b>niemals</b> mit den originalen Daten der Datenbank arbeitet, sondern immer nur mit einer lokalen Kopie.

[Stephan Weiser]

Hmh, was heisst das fuer mich im Netz ? Wenn Tquery immer nur
eine lokale Kopie beharkt, wie kann ich denn dann sicherstellen,
das Kollege am Nachbar-PC ide aktuelle Datenbank erhält

[Andreas Kosch]

Hallo,

&gt;Wie kann ich denn dann sicherstellen, das Kollege am Nachbar-PC die aktuelle Datenbank erhält?`

Die Antwort auf diese Frage hängt davon ab, welche Datenbank verwendet wird.

Im Fall einen datensatzzeigerorientierten Desktop-Datenbank (dBASE, Paradox, ACCESS etc.) ist TTable der Zugriffsweg der 1. Wahl, denn dort wird direkt ein Datensatzzeiger in der originalen Datenbank mitgeführt. Immer dann, wenn der Datensatzzeiger geändert wird oder Refresh aufgerufen wird, hat man damit automatisch topaktuelle Daten.

Im Fall einer mengenorientierten SQL-Datenbank muss der Client in jedem Fall über SQL auf den Server zugreifen, dabei spielt es keine Rolle, ob TTable oder TQuery verwendet wird (die VCL/BDE wandelt bei TTable alle Aktionen automatisch in SQL-Anweisungen um). Bei einer SQL-Datenbank hat ein Client nur dann eine (fast) aktuelle Kopie, wenn der regelmässig eine neue Transaktion startet und in diesem Transaktionskontext die SELECT-Abfrage neu ausführt.

Im Verzeichnis <i>Delphi | <b>IBX | RedSys</b></i> ist ein vollständiges Beispielprojekt für den Borland InterBase (SQL-Server) zu finden, bei dem alle x-Sekunden die Abfrage neu ausgeführt wird, damit im TDBGrid möglichst aktuelle Daten sichtbar sind. Das Programm muss nach jedem erneuten Ausführen den zuletzt ausgewählten Datensatz neu positionieren