Werte in Query ändern und committen

[messie]

Moin,

ich bin nach längerer Pause mal wieder mit meiner DB-Anwendung beschäftigt.

Ich habe eine Query, die mir Messdaten aus verschiedenen Tables einsammelt. Dazu gehört auch ein Zeitstempel.

Ich würde gerne die Anwendung so erweitern, dass die Messungen zu zeitlich unterschiedlichen Zeitpunkten partiell stattfinden können. Dazu müssten die bestehenden Daten eingelesen und ihr Zeitstempel verändert werden um Kopien und damit Redundanzen zu vermeiden. Die vorherige Messung würde damit Teil einer neueren Messung.

Vermutlich fehlt mir nur eine Kleinigkeit: ich kann die Werte in der Query nicht überschreiben, da ich nicht im Editiermodus bin.

Meine Frage: wie muss ich die Query konfigurieren damit ich geänderte Werte sicher in die DB zurück bekomme? Ich bin da ein wenig unsicher weil ich dort Daten seit 2006 zerschießen könnte.

Danke, Messie

[jobo]

dataset.edit und Du kannst den Satz editieren.

Aber vielleicht ist das auch gar nicht das Problem. Du schreibst von mehren Quellen. Eine solche Query ist idR nicht editierbar, bzw. es ist nur die Kerntabelle einer Query editierbar.

[Texas]

Als erste erst mal die daten sichern!

Ist die Query zum lesen oder schreibt sie in die DB ?
und
man kann über Parameter mit der Query arbeiten

zB query.sql.add(select * from Tabelle where Zeitstempel = :Zeit);
dann query.parambyname('Zeit').AsVariant := Now;
query.ExecSQL;

[messie]

Zitat:

Zitat von jobo (Beitrag 1296391)

dataset.edit und Du kannst den Satz editieren.

Aber vielleicht ist das auch gar nicht das Problem. Du schreibst von mehren Quellen. Eine solche Query ist idR nicht editierbar, bzw. es ist nur die Kerntabelle einer Query editierbar.

Moin,

Genau da schwimme ich wie gewöhnlich :oops:
Was ist wie verknotet?

Wenn ich Dich richtig verstehe sammele ich mir in der Query die Indizes der entsprechenden Datensätze der Messdatentabelle ein und mache dann ein UPDATE der jeweiligen Sätze?

@Texas: ich gehe über ein Query.open dran. Das ist nur readonly. Kann ich mit einen ExecSQL auch direkt schreiben?

Grüße, Messie

[Texas]

ExecSQL führt die Query neu aus und zwar mit dem Wert den man über den Parameter setzt.
kannst du mal den query.sql text zeigen. Bei query.open würde ich sagen das gelesen wird.

[mkinzler]

Zitat:

Zitat von Texas (Beitrag 1296392)

zB query.sql.add(select * from Tabelle where Zeitstempel = :Zeit);

Aber nur wenn der Abfragestring in der Komponente vorher löeer warleer ist

Besser
query.sql.Text := 'select * from Tabelle where Zeitstempel = :Zeit';
[/QUOTE]

Zitat:

query.ExecSQL;

Hier wird aber ein Open benötigt.

Zitat:

ExecSQL führt die Query neu aus und zwar mit dem Wert den man über den Parameter setzt.
kannst du mal den query.sql text zeigen.

ExecSQL führt eine Abfrage aus, ohne das eine Ergebnismenge an den Client zurückübertragen wird. das ist bei Select wenig sinnvoll.

Zitat:

Bei query.open würde ich sagen das gelesen wird.

Was man bei einem select-Statement ja auch will.

Ob eine Ergebnismenge editierbar ist hängt von der Abfrage ab. Z.B. funktioniert das bei Joins ohne Nacharbeit nicht.

[Texas]

Zitat:

Hier wird aber ein Open benötigt.

aber nicht wenn der Zeitstempel neu geschrieben werden soll oder?

Solange man nicht weiss was die Query eigentlich macht :roll:,
solange kann man auch messie bei seiner Frage nicht richtig weiterhelfen

[mkinzler]

Zitat:

aber nicht wenn der Zeitstempel neu geschrieben werden soll oder?

Das macht aber Deine Lösung nicht.

[jobo]

Zitat:

Zitat von messie (Beitrag 1296393)

Genau da schwimme ich wie gewöhnlich :oops:
Was ist wie verknotet?

Wenn ich Dich richtig verstehe ..

Also es geht primär nicht um mein Verständnis, sondern um Deins.
Wie sieht das alte System aus?
Wie soll das neue aussehen?
Soll neu und alt kompatibel sein? (Stichwort "..Daten bis 2006 zerschießen..")

Angenommen Du hast:
3 Tabellen ta, tb, tc mit Messdaten,
die Daten werden über ein Kriterium gejoint und ausgegeben Messung_ID
Teile dieser Daten sollen aktualisiert werden

Dann benötigst Du 3 Update Statements, die das je Tabelle durchführen.
Update ta set m1=.., m2=.. mn=.., zeitstempel=:zsneu where Messung_ID=:id;
Nach Bedarf ebenso für tb, tc.

Das wäre ein mögliches Vorgehen zur Korrektur "einer" Messung. Kann aber auch ganz anders gemacht werden, je nach Anforderung.

[p80286]

Zitat:

Zitat von messie (Beitrag 1296390)

Ich würde gerne die Anwendung so erweitern, dass die Messungen zu zeitlich unterschiedlichen Zeitpunkten partiell stattfinden können. Dazu müssten die bestehenden Daten eingelesen und ihr Zeitstempel verändert werden um Kopien und damit Redundanzen zu vermeiden. Die vorherige Messung würde damit Teil einer neueren Messung.

Das kommt mir seehr seltsam vor. Du hast zu irgendeinem Zeitpunkt x einen Meßwert erhalten. Dieser Meßwert liegt mit der Zeitangabe in der Datenbank. Warum willst du an der Zeitangabe "drehen"?

Warum 3 Tabellen? Werte von drei Meßstellen?

Gruß
K-H

[hoika]

Hallo,

egal, wie die Lese-Query Q1 aussieht (Join oder 3 oder 100 Tabellen),
das Update erfolgt einfach über eine separate Query Q2!

Erweitere Q1 um die benötigten Primary Keys der benötigten Update-Tabellen
und tipper die DB-Update über die Query Q2 selber zusammen.

PS:
Hoffentlich zeigst du die Daten von Q1 nicht in einem TDBGrid an
und erwartest jetzt "Inplace-Edit".


Heiko

[Dejan Vu]

Eine alternative Vorgehensweise könnte darin bestehen, die Daten in einer View bereitzustellen und die Daten über einen UPDATE-Trigger auf der View auf die einzelnen Tabellen zu verteilen. Aus Sicht der Anwendung kann man dann mit den üblichen Verdächtigen (TxxTable, TxxQuery) arbeiten. Ein weiterer Vorteil ist, das man die Tabellenstruktur nachträglich optimieren kann, ohne die Anwendung verändern zu müssen (OCP).

Wäre das RDBMS z.B. MS SQL-Server, könnten Updates direkt auf der View ausgeführt werden. Einige Provider (also der TxxQuery-Anbieter) können Updates auch auf einer Query ('SELECT * FROM A JOIN B ON xxxx') durchführen. Bei beiden Verfahren muss die Query natürlich bestimmten Anforderungen genügen (keine Aggregate, Konstanten, IIF etc.)

Ich persönlich würde aus Transparenzgründen zu einer Updatable View tendieren. Die Tabellenlogik (DDL und DML) ist dann komplett im RDBMS kodiert: Es gibt nur ein Interface (die View).

[messie]

Moin,

Hoika hat es richtig gesehen. Ich habe jetzt die Daten mit einem zweiten Query und neuem Zeitstempel inserted.

Damit habe ich einen kumulierten Verlauf der bei Nachmessungen (die vorhandene Werte überschreiben) rückführbar ist.

Danke für Eure Hilfe, Messie