Berechtigung auf Satzebene vergeben?

[RobertMack]

... wie sieht denn die Anwendung aus?

I.d.R. hat man eine Subfile (sowieso nur read) aus der man dann einen Satz zur Bearbeitung auswählt.

Wenn nun das Programm eine zusätzliche LF/JF zum Füllen der Subfile erhält, bleibt der Rest gleich. Denn wo nix auszuwählen ist ist auch nix mit Zugriff.

Gruß,
Robert, pragmatisch.

[BenderD]

Hallo,

mal ganz pragmatisch:
in der Regel öffnte man dann in dem Programm, das den Einzelsatz anzeigt dieselbe Datei, wie in dem Subfile, diesmal zum Update und Peng!

mfg

Dieter Bender

... wie sieht denn die Anwendung aus?

I.d.R. hat man eine Subfile (sowieso nur read) aus der man dann einen Satz zur Bearbeitung auswählt.

Wenn nun das Programm eine zusätzliche LF/JF zum Füllen der Subfile erhält, bleibt der Rest gleich. Denn wo nix auszuwählen ist ist auch nix mit Zugriff.

Gruß,
Robert, pragmatisch.

[Schnichels]

Hallo,

es handelt sich um die Auftragsbearbeitung und die Kundenstammbearbeitung. Beides definitiv mit UPDATE und WRITE.

Gruss

Jürgen Schnichels

[BenderD]

Hallo Jürgen,

da geht an einem Redesign der Anwendung nix vorbei!!!
1. Schritt: Erstellung einer SQL basierten separaten Datenbankzugriffsschicht, die analog zu jedem Rekord Löffel Exzess Zugriff eine Procedure anbietet, die das gleiche liefert.
2. Schritt Austausch der Rekord Löffel Exzess Zugriffe durch die entsprechenden Callp Aufrufe (geht auch mit CALL, wenns denn kein ILE ist, was ich mal so vermute).
3. In der nunmehr SQL Zugriffsschicht, kann man dann auf die Subselect Variante zurück greifen.
Wenn man das geschickt einfädelt, kann man den Aufwand durch Generierung minimieren - ganz wenig wird es nicht werden, Designschwächen werden halt bestraft.

Dieter Bender,
grundsätzlich

Hallo,

es handelt sich um die Auftragsbearbeitung und die Kundenstammbearbeitung. Beides definitiv mit UPDATE und WRITE.

Gruss

Jürgen Schnichels

[RobertPic]

1. Hier noch folgende Alternative:

Wir hatten vor den Internetzeiten, Zugänge für unsere Kunden auf die AS/400. Auch die Kunden durften mit unserer Auftragsbearbeitung arbeiten.

Wir lösten das Problem mit eigenen Bildschirm-DDS-Files, welche bei der Anmeldung vorne (in die Libl) reingehängt wurden.

In unseren Fällen war die Kundenummer einfach immer vorausgefüllt (Default) und nicht änderbar (Achtung! muss ein Inputfeld bleiben, sonst Lvlchk). Ob es in deinem Fall mit vorausgefüllten und gesperrten Feldern geht, kann ich für deine Applikation nicht sagen. Bei uns wäre das auch mit der Verkäufernummer gegangen.

2. Noch zum Thema Joinlog + WRITE und UPDATE:

Ob das funktioniert, hängt natürlich von der Machart der Applikation ab.

Mitunter wird das Subfile ja wegen der Sortierung aus einer logischen Datei aufgebaut (diese ist dann zur Joinlogischen "hingebogen"), wenn der Auftrag/Kunde ausgewählt wurde, wird wieder mit der PF-Datei gearbeitet, welche aber kein Override benötigt, da der Sachbearbeiter bereits vorher eingeschränkt wurde.

Eventuell kommt man ja mit einem Mix aus 1 und 2 hin.

LG Rob

PS: Wenn es irgendwie geht, schmeiße ich 3GL-Programme natürlich weg und schreibe sie mit LANSA/VB6/VB.NET/Access/Perl neu