Update per Sql mit externer Datenstruktur

[tarkusch]

Hallo,

wir haben eine Artikeldatei die als Keyfelder Firmennummer, Datum, und Artikelbezeichnung hat.

Ich habe jetzt ein Wartungsprogramm geschrieben, wobei ich ein Problem mit Artikel die 2 oder mehrmals am selben Tag gebucht werden.

Mit Chain auf die Datei bekomme ich ja jedesmal die erste Buchung sodas ich die 2. 3. etc. nie ändern kann.

Jetzt habe ich einfach seq. in der Datei weitergelesen bis das Erstellungsdatum und Uhrzeit(6 stellig) übereinstimmt.
Aber das Problem ist das Updaten der Datei

Fortschreiben oder Löschen in Datei ARTIKELP ohne vorherige
Eingabeoperation (C G D F).

Da ich ja in MyDs die aktuellen Felder hab, kann ich per Sql im Programm ein update mit MyDs durchführen?
D MyDS E DS ExtName(ARTIKELP)

Dank im Voraus

TARKI

[Fuerchau]

Die Fehlermeldung beim Update bedeutet ja nur, dass du ohne Sperre (InputFile oder READ ohne Sperre) gelesen hast.

Natürlich kannst du per SQL updaten, wenn du einen eindeutigen Schlüssel für den Satz hast.
Bedenke aber, dass ein Update nicht über die Struktur laufen kann. Du musst die Felder dann schon einzeln kodieren:

update myfile
set
F1 = : MyF1
,F2 = : MyF2
:
where Fx = : MyFx

[mk]

Hallo,

wir haben eine Artikeldatei die als Keyfelder Firmennummer, Datum, und Artikelbezeichnung hat.

Ich habe jetzt ein Wartungsprogramm geschrieben, wobei ich ein Problem mit Artikel die 2 oder mehrmals am selben Tag gebucht werden.

Mit Chain auf die Datei bekomme ich ja jedesmal die erste Buchung sodas ich die 2. 3. etc. nie ändern kann.

Jetzt habe ich einfach seq. in der Datei weitergelesen bis das Erstellungsdatum und Uhrzeit(6 stellig) übereinstimmt.
Aber das Problem ist das Updaten der Datei

Fortschreiben oder Löschen in Datei ARTIKELP ohne vorherige
Eingabeoperation (C G D F).

Da ich ja in MyDs die aktuellen Felder hab, kann ich per Sql im Programm ein update mit MyDs durchführen?
D MyDS E DS ExtName(ARTIKELP)

Dank im Voraus

TARKI

Hallo,

Die Fehlermeldung sagt ganz klar:

Einen Datensatz ändern ohne den Satz vorher zu lesen geht im
RPG nicht ....................

Mit Sql geht das da Du dort die Schlüsselfelder
i.d.R. mit angibst.


Da musst Du dein Programm wohl noch ändern.

Gruß
Michael

[mk]

Hallo,

Einen Datensatz ändern ohne den Satz vorher zu lesen geht im
RPG nicht ....................

Hi,

na klar kann man Sätze wie auch immer ändern
RRN etc. .....

Man sollte aber schon verstehen das im RPG
erst ein Read / Chain auf einen Satz gemacht werden
sollte um ihn zu ändern.

[tarkusch]

Hallo,

ich habe das Chain durch ein reade ersetzt und bekamm die Meldung.
Andreas Lösung trifft genau mein Problem.
Danke und noch einen schönen Abend.

Grüße

Tarki

[Fuerchau]

Ich weiß nicht, warum du zusätzlich SQL verwendest, wenn du die Datei doch schon mit RPG öffnest und liest.
Wenn dir der Key für Datum/Zeit fehlt so lege doch eine LF mit diesem Schlüssel an.

Auch für den Update per SQL ist ein Index/DDS-LF allein aus Performancegründen schon erforderlich.

Ein SQL-Update mit " where RRN(File) = nnn " ist der allerschlechteste Weg, da hier grundsätzlich die gesamte Tabelle durchsucht wird, selbst wenn der eigentliche Satz schon längst bearbeitet wurde.

[andreaspr@aon.at]

Ein SQL-Update mit " where RRN(File) = nnn " ist der allerschlechteste Weg, da hier grundsätzlich die gesamte Tabelle durchsucht wird

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.

Dennoch würde ich nicht diesen Weg empfehlen, da nicht gewährleistet werden kann, dass der gewünschte Satz:
*) nicht schon geändert wurde
*) in der Tabelle plötzlich an einer ganz anderen Stelle steht (REORG)

lg Andreas

[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