Wo lege ich Benutzereinstellungen ab

[ggscholz]

Hallo in die Runde,

gegeben: Windows-Arbeitsplatzrechner, die von verschiedenen Personen über den Tag benutzt werden und mit dem Benutzer Team angemeldet sind. Alle starten eine auf einem Serververzeichnis abgelegte exe

bisher speichere ich programmspezifische Einstellungen in einer INI Datei, die als RECHNERNAME.INI in einem zentralen Verzeichnis der Anwendung abgelegt ist. Kommt ein neuer Rechner dazu, gibt es eine neue Ini-Datei. In der Ini-Datei steht z.B. die Größe des Anwendungsfensters, welche Oberfläche eingestellt ist, Angaben zum Drucker, Ausdruck mit oder ohne Vorschau oder Drucken auf einem Etiketten-Drucker. Beim Programmstart wird die Ini gelesen, wärend der Benutzung des Programms werden die Daten eher selten abgefragt, bei einer Änderung der Einstellungen dann natürlich gespeichert.

Funktioniert bisher ohne Probleme. Jetzt überarbeite ich mein Programm gerade, da würde ich gerne wissen, ob das noch State of the Art ist

Mein Frage: wo legt man diese Rechnerspezifischen Daten ab. Vor jetzt mehr als 20 Jahren habe ich mich für die Ini Datei entschieden, die Registry (gab's die da schon) stand vielleicht auch noch zur Wahl.

Legt man solche Daten in der sowieso benutzten Datenbank ab?

Über ein paar Anregungen würde ich mich freuen!!

Beste Grüße

gerd

[Uwe Raabe]

Zitat von ggscholz:

wo legt man diese Rechnerspezifischen Daten ab.

Dafür bietet sich TPath.GetPublicPath an.

Die INI-Datei selbst ist OK.

[tewes]

Hallo,

meine Gedanken/Anregungen:
1. Rund um die exe auf dem Server sollten Benutzer eigentlich keine Schreibberechtigung haben
2. GetPublicPath liegt lokal auf dem Client. Nach einem Wechsel der Festplatte sind die Einstellungen weg.
3. Mögliche Lösung: Tabelle in Datenbank, z.B. ini_local(Rechnername, Ident, Value)

[Phoenix]

Zitat von ggscholz:

Legt man solche Daten in der sowieso benutzten Datenbank ab?

Wenn Du eh schon eine DB hast, spricht grundsätzlich nichts dagegen das auch dort abzulegen.

Ansonsten gibt es das %AppData% Verzeichnis, dort sollten anwendungsspezifische Daten lokal abgelegt werden.

[Uwe Raabe]

Zitat von Phoenix:

Ansonsten gibt es das %AppData% Verzeichnis, dort sollten anwendungsspezifische Daten lokal abgelegt werden.

%APPDATA% ist aber User-spezifisch und auch noch rechnerübergreifend:

Zitat:

APPDATA=C:\Users\Uwe\AppData\Roaming

Besser wäre %ALLUSERSPROFILE%:

Zitat:

ALLUSERSPROFILE=C:\ProgramData

Das ist aber auch genau das, was TPath.GetPublicPath zurückliefert.

Zitat von tewes:

2. GetPublicPath liegt lokal auf dem Client. Nach einem Wechsel der Festplatte sind die Einstellungen weg.

Das gilt aber für alle Dateien auf der Festplatte, solange man die nicht sichert und wiederherstellt. Wenn Datenverlust ein Problem ist, dann gilt das für jeden anderen Speicherort genauso.

Ich habe in der Regel so meine Bedenken zum Speichern von Settings in der Produktivdatenbank. Die sind nämlich nach Einspielen eines Backups potentiell ebenfalls weg. Die meisten Anwender (zumindest die ich kenne) gehen nicht davon aus, dass das Einspielen eines älteren Datenbestands auch ihre Settings verändert.

[Stevie]

Zitat von Uwe Raabe:

Ich habe in der Regel so meine Bedenken zum Speichern von Settings in der Produktivdatenbank. Die sind nämlich nach Einspielen eines Backups potentiell ebenfalls weg. Die meisten Anwender (zumindest die ich kenne) gehen nicht davon aus, dass das Einspielen eines älteren Datenbestands auch ihre Settings verändert.

Das kommt wohl sehr auf den Blickwinkel, die Settings und die Anwendung im Detail an - wenn man sich von verschiedenen Rechnern mit der Anwendung anmelden kann, dann erwartet man auch, dass die entsprechenden Einstellungen auf allen Rechnern gleich sind.

[Uwe Raabe]

Ich gebe dire recht, dass dies für Einstellungen, die sowohl rechner- als auch user-bezogen gleich sein sollen, ds Speichern in einer DB sinnvoll sein kann.
Allerdings ging es in dem Eingangspost genau darum, dass die Einstellungen rechnerbezogen sein sollen.

[TigerLilly]

Ich habe gerade bei Leuten im Home Office erlebt, dass es keine gute Idee ist, wenn alle Settings nur benutzerspezifisch sind. Fenstergrößen - und positionen müssen zum verwendten Monitor passen und da ist zwischen Office und Home Office oft ein Unterschied. Ich tendiere mittlerweile eher zu einer Kombi aus Rechner+Benutzer.
Aber ich bin auch eher dafür, die Settings in der DB zu speichern. da werden sie jedenfalls gesichert und ein Restore ist ohnedies nichts alltägliches und setzt eben die Daten UND Einstellungen auf Tag X zurück.