AW: Programm Datenverifizierung
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. |
AW: Programm Datenverifizierung
Zitat:
Zitat:
|
AW: Programm Datenverifizierung
Zitat:
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? |
AW: Programm Datenverifizierung
Das hast Du wohl falsch verstanden, für den Hash brauchst Du keine Adminrechte.
|
AW: Programm Datenverifizierung
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.
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. |
AW: Programm Datenverifizierung
Hmmm, ein Backup kann nur zurückgespeilt werden, wenn dieses neuer ist ... macht ja irgendwie keinen Sinn mit dem Backup :mrgreen:
Eine weitere Möglichkeit (zum Verstecken in den AppData-Foldern) wäre:
|
AW: Programm Datenverifizierung
Zitat:
Ansonsten muss der User eben informiert werden, was er da tut oder sogar ein Zusammenführen der Datensätze angeboten werden. |
AW: Programm Datenverifizierung
Sqlite unterstützt eine Schema-Version und eine User-Version.
Da haben die Programmierer mal eine richtig gute Idee gehabt. :thumb: Mit der Schema-Version kann deine Anwendung überprüfen, ob die Datenbank strukturiell neu genug ist. Hier etwas Pseudecode:
Delphi-Quellcode:
Die User-Version kannst du für eigene Zwecke benützen.
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.'); 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. |
AW: Programm Datenverifizierung
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:
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.
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; |
AW: Programm Datenverifizierung
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.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz