ReadOnly = True und Benutzer kann trotzdem löschen

[Der schöne Günther]

Die Doku zu UpdateOptions spricht:

Zitat:

To guarantee that users cannot modify the dataset data, set ReadOnly to True. The property is the shortcut for the EnableDelete, EnableInsert, or EnableUpdate properties.

Leider scheint das nicht die Wahrheit zu sein denn ich sage sowohl auf meiner

Delphi-Quellcode:

TFDConnection

als auch auf einer

Delphi-Quellcode:

TFDTable

:

Delphi-Quellcode:

UpdateOptions.ReadOnly := True;

.

Später führt er aber ein

Delphi-Quellcode:

connection.ExecSQL('DELETE FROM myDatabase WHERE stuff.id = :id', [someId]);

fröhlich aus und löscht den Datensatz aus der Tabelle. Das finde ich ehrlich gesagt schon ein bisschen sehr harsch.


Ist das ein Bug oder findet jemand einen kreativen Weg wie man das als "as designed" abstempeln könnte?

[jaenicke]

Das sind ja zwei Paar Schuhe. Die Einstellung betrifft die Daten im Dataset, was du machst ist eine SQL Anweisung ausführen.

Dass die vorher entsprechend der Einstellung kategorisiert wird, hätte ich jetzt auch nicht erwartet. Denn schließlich löst du die ja selber aus.

[Papaschlumpf73]

Das ReadOnly bezieht sich nicht auf die Datenbank sondern nur auf das DataSet von TFDTable. FDTable.Edit oder FDTable.Delete werden dann nicht funktionieren.

Wenn du aber den Delete-Befehl direkt zur Datenbank schickst, gelten nur die Rechte, die der User auf dem DB-Server selbst hat.

In der Doku steht es auch so drin: To guarantee that users cannot modify the dataset data

[himitsu]

Da wirst du wohl in der Datenbank an der Tabelle die Roles/Permissions/... entsprechend einrichten müssen, so dass der eingeloggte User keine Berechtigungen für UPDATE und DELETE besitzt.

[Der schöne Günther]

Warum kann ich diese Einstellungen dann überhaupt an einer TFDConnection vornehmen? Hätte ich das direkt auf einer Tabelle gemacht, sehe ich das ja ein. Aber so?

Ich hätte den jetzt schon für so schlau gehalten dass er z.B. ein SQL-Select-Statement durchlässt, bei etwas wie DELETE aber abblockt.

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1360344)

Warum kann ich diese Einstellungen dann überhaupt an einer TFDConnection vornehmen?

Man kann die DataSets einzeln auf ReadOnly setzen
oder man setzt das global für alle DataSets, in der Connection.

Diese ReadOnly setzen das DataSet auf ReadOnly und damit auch die angehängteh DBControls (Edits/Grids), die sich dann garnicht erst "editieren" lassen (vor dem POST).
Ein DB-seitiger Schreibschutzt wird erst beim POST bemerkt, falls die DB-Query-Componenten das nicht vorher mitbekommen und beim Laden der Daten das ReadOnly der TField aktivieren.

[jobo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1360344)

Warum kann ich diese Einstellungen dann überhaupt an einer TFDConnection vornehmen? Hätte ich das direkt auf einer Tabelle gemacht, sehe ich das ja ein. Aber so?

Ich hätte den jetzt schon für so schlau gehalten dass er z.B. ein SQL-Select-Statement durchlässt, bei etwas wie DELETE aber abblockt.

Du verwendest da 2 unterschiedliche API, die verschieden mächtig (und wenig intelligent) sind.
Die Readonly Attribute der Komponenten sind sicher wasserdicht (in ihrer Welt).
Aber das SQL Statement, geht uninterpretiert (von der Connection Componente) einfach durch an die sql engine. Die SQL Engine kümmern die Delphi Settings gar nicht. Kennt sie ja auch nicht.
Und die Delphi Connection kümmert der SQL Befehl nicht, den müsste sie ja quasi parsen um eine Verletzung der Readonly attribute festzustellen. Ich schätze, es gibt keine SQL Komponente, die sich so wichtig nimmt.

[Der schöne Günther]

Alles klar.

Dass es so ist verstehe ich, ich hätte halt erwartet dass FireDAC in der Mitte den String nicht einfach 1:1 durchschießt sondern das ReadOnly sich noch einmal ansieht und selbst schon abblockt. :?

[Daniel]

Zitat:

Zitat von Der schöne Günther (Beitrag 1360360)

[...]sondern das ReadOnly sich noch einmal ansieht und selbst schon abblockt. :?

Das kannst Du client-seitig nicht zuverlässig umsetzen. Einen Datensatz könntest Du z.B. auch durch das Ausführen einer Stored-Procedure löschen. Oder meinetwegen auch in einem Trigger: Tabelle A wird aktualisiert und löscht in Tabelle B einen Datensatz.
Die Kontrolle über das, was im DataSet passiert, ist das einzige, was client-seitig sichergestellt werden kann und auch wird.

[jobo]

Vielleicht noch etwas Licht an die Sache werfen:
Wenn Dein Delete Statement als Delete-SQL in den Dataset Properties eingetragen wäre (und nicht per COnnection.EXECSQL rausgejagt würde), dann wäre ich mit meiner Erwartung an die Readonly Property der Dataset Komponente voll auf Deiner Seite. Die wäre dann schlampig implementiert.

Aber so.. ein hintenrum SQL Befehl.. keine Chance..