Programm Datenverifizierung

[Sir Rufo]

Ich weiß nicht, ob ich mir darüber groß Gedanken machen würde, den User so extrem vor sich selber zu beschützen ... wenn der da was "kaputt" machen will -> sein Problem.

Ich würde allerdings solche Daten auch an einem Ort speichern, der normalerweise für den User nicht sichtbar ist (AppData Local oder Roaming).

Wenn der da jetzt auch noch drin rumpfuscht, dann gibt es für den was auf die Mütze.

[DeddyH]

Zitat von Sir Rufo:

wenn der da was "kaputt" machen will -> sein Problem.

Zitat von DeddyH:

wenn ein Benutzer mit aller Gewalt Mist machen will, dann ist er auch selbst dafür verantwortlich.

Ich sehe, wir sind da einer Meinung

[Andidreas]

Zitat von DeddyH:

Zitat von Sir Rufo:

wenn der da was "kaputt" machen will -> sein Problem.

Zitat von DeddyH:

wenn ein Benutzer mit aller Gewalt Mist machen will, dann ist er auch selbst dafür verantwortlich.

Ich sehe, wir sind da einer Meinung

ich stimm euch da völlig zu... am anfang dachte ich auch die werden an sowas nicht rumspielen, aber die erfahrung zeigt das sies doch machen, und das doofe is das wir als IT dann wieder die daten irgendwie wiederherstellen müssen...
da die tools aber eh neu gemacht werden sollen, werd ich wohl in die richtung gehen das die daten irgendwo abgelegt werden wo se der user net findet...

lt. luckie geht das mit dem hash ja nur über admin rechte... gibt es noch andere alternativen?

[DeddyH]

Das hast Du wohl falsch verstanden, für den Hash brauchst Du keine Adminrechte.

[BUG]

Das Problem sehe ich hier:
In dem Moment, indem der User die Datenbank mit dem Backup überschreibt, ist diese verloren. Dem User dann noch mit einem Hashwert mitzuteilen, dass er etwas falsch gemacht hat, hilft niemanden.

Betrachte es mal anders: Anscheinend sucht der Kunde eine Möglichkeit ein Backup zu machen.
Also biete ihm eine an, die du kontrollierst.

1. der User kann ein Backup anlegen
2. der User kann ein Backup importieren, wenn es neuer ist
   (ansonsten nachfragen oder/und mergen)
3. außerdem kopierst du bei Programmende die jeweils aktuellste Datenbank an eine Stelle, die der User nicht findet/überschreibt
   (vielleicht auch alle aktuellen Versionszweige, wenn jemand sehr rumsaut)
4. wenn jetzt ein Nutzer eine alte Kopie zurückschreibt, gehst du vor wie bei 2. und gibst eine böse Fehlermeldung aus, so das er es nicht nochmal macht.

Das Datum der letzten Änderung schreibst du einfach in die Datenbank und in die Registry.

Wenn du das mergen geschickt realisierst, können die Benutzer sogar untereinander Datensätze tauschen.

[Sir Rufo]

Hmmm, ein Backup kann nur zurückgespeilt werden, wenn dieses neuer ist ... macht ja irgendwie keinen Sinn mit dem Backup

Eine weitere Möglichkeit (zum Verstecken in den AppData-Foldern) wäre:

• Datei selber mit dem Attribute HIDE versehen
• Datei mit einem Schreibschutz versehen (beim Programmstart entfernen und am Ende wieder setzen)

Der Schreibschutz hält natürlich den "advanced" User nicht auf, diese Datei doch zu löschen, aber da kann keiner mehr sagen "aus Versehen"

[BUG]

Zitat von Sir Rufo:

Hmmm, ein Backup kann nur zurückgespeilt werden, wenn dieses neuer ist ... macht ja irgendwie keinen Sinn mit dem Backup

Naja, neuer ist es, wenn es über Neuinstallation des Programms oder ein von einem Image neu aufgesetztem System geschrieben wird.
Ansonsten muss der User eben informiert werden, was er da tut oder sogar ein Zusammenführen der Datensätze angeboten werden.

[shmia]

Sqlite unterstützt eine Schema-Version und eine User-Version.
Da haben die Programmierer mal eine richtig gute Idee gehabt.
Mit der Schema-Version kann deine Anwendung überprüfen, ob die Datenbank strukturiell neu genug ist.
Hier etwas Pseudecode:

Delphi-Quellcode:

if SchemaVersion < CURRENT_SCHEMA_VERSION then
   MsgBox('Achtung: Datenbankstruktur ist zu alt! Weitermachen auf eigene Gefahr.')
else if SchemaVersion > CURRENT_SCHEMA_VERSION + 3 then
   MsgBox('Achtung: Anwendungsprogramm könnte zu alt für die Datenbank sein.');

Die User-Version kannst du für eigene Zwecke benützen.
Bei jedem Programmende zählt deine Anwendung die User-Version um Eins hoch und speichert diesen Wert in einer Ini-Datei oder Registry.
Sollte beim Programmstart eine Abweichung zwischen dem gespeicherten Wert und der aktuellen User-Version gibt es einen Hinweis an den Benutzer.
Ausserdem wird in einem Flag gespeichert, dass es eine Abweichung gegeben hat.
Bei gesetztem Flag muss die Anwendung am Ende fragen ob die Datenbank als aktiv gelten soll;
falls User mit "Nein" antwortet unterbleibt das Hochzählen der User-Version.

[neo4a]

Bei kleinen DB hat sich bei mir folgender Ansatz bewährt:

- Erzeuge die DB (intern und dynamisch) immer neu (hier CDS).
- Öffne die gespeicherte DB (hier tempCDS).
- Kopiere die Felder etwa so:

Delphi-Quellcode:

  begin
    tempCDS := TClientDataset.Create(nil);
    sl      := TStringList.Create;
    try
      tempCDS.LoadFromStream(aStrStream);
      tempCDS.Open;
      sl.Text := tempCDS.FieldList.Text;
      while not tempCDS.Eof do
      begin
        CDS.insert;
        for i := 0 to CDS.FieldCount - 1 do
        begin
          s := CDS.Fields[i].FieldName;
          if sl.IndexOf(s) > -1 then
            CDS.FieldByName(s).Value := tempCDS.FieldByName(s).Value;
        end;
        CDS.post;
        tempCDS.Next;
      end;
      tempCDS.Close;
    finally
      sl.free;
      tempCDS.Free;
    end;

Vorteil dieser Methode: Man übernimmt, was nur geht und lässt weg, was nicht mehr geht. Natürlich kann man den Ansatz auch etwas anpassen und zuvor erst einmal so den Strukturunterschied feststellen, den Anwender fragen, was zu tun ist, und entsprechend weiter gehen.

[Luckie]

also ich bin davon abgekommen extra Sicherheitsmaßnahmen zu ergreifen. Ich mache nur das was das OS von sich aus hergibt. Wenn der Benutzer eine Linux-Live-CD einschiebt und die Daten löscht...selber schuld. Ich meine Autohersteller haben auch keine Sicherheitsmaßnahmen, dass man keinen Zucker in den Tank schütten kann oder sich selbst die Bremsschläuche durchschneiden.