Update per Sql mit externer Datenstruktur

[B.Hauser]

Das halte ich für ein Gerücht!!
Die RRN definiert eine eindeutige Zeile in der Tabelle. Da braucht ncht die gesamte Tabelle durchsucht werden.
Die Datenbank schlüsselt diese Nummer intern auf und greift direkt auf den Satz zu.

Andreas,
auch wenn die Relative Satz-Nr. eindeutig eine Zeile definiert, kann die relative Satz-Nr. vom SQL-Optimizer nicht als Zugriffsweg verwendet werden.
Relative Satz-Nr. sind NICHT Standard-SQL!

Zugriffswege können nur über existierende Spalten oder über neue Spalten, die in SQL Indices oder logischen Dateien definiert werden.
RRN(File) ist bei der Erstellung von neuen Spalten in SQL Indices nicht zulässig.

Deshalb kann der Optimizer nicht über einen Index-Access zugreifen, sondern muss eine andere Methode wählen. Unter der CQE wurde grundsätzlich ein Table Scan (wie Baldur beschreibt) verwendet, seit SQE kann stattdessen fast immer eine Table Probe verwendet werden, d.h. der Satz wird erst gelesen, wenn er gefunden wurde.
Table Probes sind zwar um einiges schneller als Table Scans, da die Daten erst gelesen werden, wenn der Satz gefunden wurde, aber dennoch wesentlich langsamer als ein Index Access oder Zugriff über Chain in RPG.

@Tarkusch,
wenn Du schon die Datensätze via RPG liest, warum machst Du dann nicht den Update direkt mit RPG?
Datei als Update-Datei definieren und schon kann man den gelesenen Satz updaten.

Birgitta

[Anton Gombkötö]

... kann er das Programm mit UPDATE gar nicht umwandeln. Klingt eher nach einem No-Lock-Extender bei der Lese-Operation, also CHAIN(N).
Aber das traute ich mich ob der Trivialität ursprünglich gar nicht schreiben.
Jetzt schon. :-)

[Fuerchau]

Deshalb verstehe ich die Diskssion hier auch nicht, "FMYFILE UF K DISK" und gut ist.

Die Benutzung einer Funktion beim where führt äusserst selten zu einem Direktzugriff.
Inzwischen kann man für solche Fälle z.T. (z.B. nicht bei RRN) "computed Indizes" verwenden, aber die sind meist doch nicht besonders zu empfehlen.

[andreaspr@aon.at]

Andreas,
auch wenn die Relative Satz-Nr. eindeutig eine Zeile definiert, kann die relative Satz-Nr. vom SQL-Optimizer nicht als Zugriffsweg verwendet werden.
Relative Satz-Nr. sind NICHT Standard-SQL!

Von Zugriffsweg habe ich auch nichts geschrieben. Die DB ermittelt über eine sogenannte "Values List" intern die genaue Adresse.
Es wird jeden falls nicht zwangsläufig ein Table-Scann durchgeführt ... außer man macht sowas wie ...
WHERE RRN(t1) > xxx and RRN(t1) < xxx.

Dass kann man sich auch im Debug oder Visual Explain sehr gut anschauen lassen.

In Oracle z.B. ist es noch schneller. Dort ist die RRN nicht nur eine fortlaufende Nr. sondern beinhaltet auch gleich die Information wo im Speicher sich der Satz befindet.

Aber wie schon gesagt, empfehlen würde ich es trotzdem nicht.

lg Andreas

[mk]

Bei allem SQL,

selbst heute gibt es noch Entwickler die Daten über LF's lesen
und mit der RRN die physische Tabelle schreiben und ändern.


Gruß
Michael

PS:Kenne Leute die Suibfiles mit update geöffnete
Dateien schreiben

[Fuerchau]

Nun ja, bzgl. RRN hat sich ja ab V6 wohl was getan.

In native Zugriffen per Chain war so was ja noch z.T. normal, aber in SQL-Zeiten...