Benötigte Informationen für eine Anwendung speichern

[f4k3]

Moin Moin liebe DPler

Ich stehe vor dem Problem, dass ich Informationen benötige um meine Datenbank zu initialisieren aber nicht weiß wohin ich die Informationen speichern soll beziehungsweise welche Methode dafür zu nutzen.

Meine Anwendung speichert Anwenderinformationen in einer Firebird-Datenbank.
Als Firebird Server habe ich den Firebird Super-Server am laufen.

Innerhalb meiner Anwendung greife ich über die ZEOS Komponenten auf die Datenbank zu.

Damit meine Anwendung flexibel bleibt kann der Connect String, der den "Pfad" zur Datenbank enthält, natürlich geändert
werden. Wenn zur Laufzeit die Datenbank auf die zugegriffen werden soll geändert wird, ist dass alles kein Problem. Ich muss aber innerhalb meiner Anwendung die Informationen, den Connect String, irgendwie speichern, damit ich beim nächsten Start automatisch die
Verbindung zur Datenbank herstellen kann.

Also ist ein Kriterium der Anwendung dass diese Information gespeichert wird.
Das zweite Kriterium ist dass die Anwendung auf Windows XP und Windows Vista lauffähig sein soll.
Und als drittes Kriterium ist zu nennen, dass die Daten nur über die Anwendung manipulierbar sein sollten.

Von Visual Studio 2008 kenn ich die Möglichkeit, in den Projekt-Eigenschaften Variablen zu definieren, die gelesen
und auch beschrieben werden können.

Visual Studio Beispiel:
Ich könnte eine Stringvariable definieren, in der ich den Datenbankpfad hinterlegen kann.
Wenn ich den Wert dieser Variable verändere, wird diese gespeichert und der neue Wert steht mir,
bis zur nächsten Änderung, bei jedem Neustart zur Verfügung. Wie Visual Studio diese Werte
speichert weiß ich leider nicht.

So ... ich hab in CodeGear RAD Studio 2007 keine vergleichbare Möglichkeit gefunden und nehme an
dass es so eine Möglichkeit auch nicht gibt.

Nun hab ich mir überlegt was für Möglichkeit mir zur Verfügung stehen:

1. Informationen in die Registry schreiben
Ich könnte einen Key in der Registry speichern und dort den Pfad auslesen.
Für meine Begriffe zählt dies aber nicht zum guten Stil einer Anwendung und möchte es tunlichst vermeiden Daten
in der Registry zu speichern.

Gründe hierfür sind:
- Ein Anwender mit genug Hintergrundwissen könnte den Wert in der Registry ändern und somit die Informationen inkonsistent machen.
- Die Registry wird bereits von genug Softwareentwicklern aufgebläht.

2. Informationen in einer Datei speichern
Ich hätte die Möglichkeit Informationen in eine Datei zu schreiben und diese auf einer lokalen Festplatte zu speichern.
Dank der UAC von Vista müsste ich überprüfen welches Betriebsystem eingesetzt wird. Um eine Datei zu speichern benötige ich
ein Admin-Token dass meiner Anwendung erlaubt eine Datei überhaupt auf die Festplatte zu schreiben.
Auch diese Variante möchte ich ungern nutzen, da nicht gesagt ist ob in windows 8 oder 9 überhaupt eine UAC zum Einsatz kommt oder Microsoft wieder ein anderes Verfahren einsetzt um unberechtigte Dateizugriffe zu kontrollieren. Hinzu kommt noch dass
die Datei wieder manipuliert werden kann.

3. Informationen in eine Tabelle der Datenbank speichern
Diese Variante verfällt bereits im Vorfeld, da ich zur Datenbank eine Verbindung aufbauen müsste in der die Informationen stehen, aber die Informationen bereits vorher benötige.

Ich hoffe ich habe meine Ansätze verständlich erläutert.

Nun meine eigentliche Frage ...
Wie speichert ihr Informationen die ihr für die korrekte Auführung eurer Anwendung benötigt?

Vielen Dank für eure Posts

Euer f4k3

[Bernhard Geyer]

Zitat von f4k3:

2. Informationen in einer Datei speichern
Ich hätte die Möglichkeit Informationen in eine Datei zu schreiben und diese auf einer lokalen Festplatte zu speichern.
Dank der UAC von Vista müsste ich überprüfen welches Betriebsystem eingesetzt wird. Um eine Datei zu speichern benötige ich
ein Admin-Token dass meiner Anwendung erlaubt eine Datei überhaupt auf die Festplatte zu schreiben.

Du brauchst kein Admin-Token. Du mußt nur eine Ort aussuchen auf dem du seit NT-Basierte Systemen schreibrechte hast. Hier wäre der "Eigene Dateien" oder "AppData"-Ordner oder "Gemeinsame Daten"-Ordner zu nennen. Also muß man schon seit ca. 15-20 Jahre unter Windows berücksichtigen das ein Prozess nicht überall schreiben darf.

Zitat von f4k3:

Hinzu kommt noch dass die Datei wieder manipuliert werden kann.

Einfach verschlüsseln oder Checksumme/Hash verwenden und das Problem ist keines

[jaenicke]

Die Registry ist durchaus dafür geeignet. Man kann aber durchaus auch XML-Dateien oder ein eigenes Format (FileStream) nehmen, muss aber das Anwendungsdatenverzeichnis nehmen (Rechte, wie du sagtest). Zudem könnte man eine portable Installation anbieten.

Bei INIs ist das Problem, dass die delphieigenen Funktionen auf als veraltet markierten API-Funktionen basieren, die nur noch zur 16-Bit-Kompatibilität vorhanden sind (INI --> Windows 3.1). Deshalb kann es passieren, dass die in einer kommenden Windowsversion fehlen.

Ich habe mir zu dem Thema einige Gedanken gemacht:
http://www.delphi-library.de/viewtop...=541638#541638

Zudem habe ich eine erste Alphaversion einer entsprechenden Verwaltungsklasse veröffentlicht.
http://www.delphi-forum.de/viewtopic.php?p=562996
Mittlerweile bin ich da weiter und habe das ganze nochmal stark vereinfacht. (Weil ich die Unit in eigene Projekte einbaue und dabei ein paar Ideen noch hatte.)

Du kannst dir das ja schon einmal anschauen, ich werde davon heute oder Morgen eine verbesserte Beta-Version veröffentlichen.

[f4k3]

Zitat von Bernhard Geyer:

Einfach verschlüsseln oder Checksumme/Hash verwenden und das Problem ist keines

mhm ... okay ... dann bin ich anscheinend nicht ausreichend informiert

Müsst ich mir nur noch ankucken wie man eine Datei verschlüsselt.
Ich nehme per Chiffrierung oder?

[jaenicke]

Da es bei dir nur um Datenkonsistenz geht, reicht es ja, wenn du eine Darstellung verwendest, mit der der Benutzer nichts anfangen kann. Zum Beispiel für einen String alle Zeichen als hexadezimale Asciiwerte. Dann kommt niemand mehr auf die Idee da manuell etwas zu ändern.

Dazu noch eine Prüfsumme wie angesprochen um Änderungen zu bemerken.

Eine andere Idee wäre, die Daten normal in lesbarer Form zu speichern und bei einer Manipulation (Prüfsumme) zu fragen, ob die Informationen so korrekt sind und übernommen werden sollen. Denn unabsichtlich wird kaum jemand etwas an einer solchen Konfigurationsdatei in den Anwendungsdaten ändern.

[Nersgatt]

Also, ich würde mir darum, dass der User was manuell ändert, keine Gedanken machen. Wenn er die Daten nicht über das Programm ändert und es dann nicht mehr zusammen passt, ist er einfach selbst schuld. Fertig.
Und es ist ja auch nicht wirklich tragisch, wenn man der Connectionstring zur DB nicht mehr passt. Dann gibt es beim Programmstart halt eine Fehlermeldung "Datenbank konnte nicht geöffnet werden" und der Dialog für die Einstellungen öffnet sich.

Diese Daten in der Registry zu speichern, wäre wohl der Weg, den sich MS wünscht.

Die Einstellungen in einer Datei zu speichern hat meiner Meinung nach den Vorteil, dass man die Datei einfach kopieren kann, um sie auf einen anderen Rechner zu übertragen. Klar, kann man bei der Regitry-Methode auch, aber erklär das mal einem Kunden am Telefon...
Dazu kommt die Möglichkeit, z.B. per Parameter den Pfad zu Konfigurationsdatei mitzugeben. Dann kann man das Programm mit verschiedenen Konfigurationen starten, indem man einfach die Verknüpfung ändert.

Ob man nun die Daten in einer INI, einer XML oder gar in einem eigenen Format speicher, das ist jedem selbst überlassen.

[f4k3]

Zitat von jaenicke:

Da es bei dir nur um Datenkonsistenz geht, reicht es ja, wenn du eine Darstellung verwendest, mit der der Benutzer nichts anfangen kann. Zum Beispiel für einen String alle Zeichen als hexadezimale Asciiwerte. Dann kommt niemand mehr auf die Idee da manuell etwas zu ändern.

Dazu noch eine Prüfsumme wie angesprochen um Änderungen zu bemerken.

Eine andere Idee wäre, die Daten normal in lesbarer Form zu speichern und bei einer Manipulation (Prüfsumme) zu fragen, ob die Informationen so korrekt sind und übernommen werden sollen. Denn unabsichtlich wird kaum jemand etwas an einer solchen Konfigurationsdatei in den Anwendungsdaten ändern.

Okay ... ich denk ich nehm die Umwandlung ins Hexadezimal ... mit der Prüfsumme bin ich mir noch unsicher. kommt drauf an wie aufwendig so ein verfahren ist. Hab mich bisher noch nicht damit beschäftigt. Ich hab mir deinen Eintrag mal angekuckt ... jetz wäre es nicht schlecht eine Funktion zu haben die mir den Pfad ermittelt:

C:\Dokumente und Einstellungen\[user]\Anwendungsdaten

Der Pfad wäre für meine Anwendung ideal, da die Anwendung bei uns intern eingesetzt wird und daher von jedem PC mit den korrekten Daten versorgt werden würde.

Da würde sich ja die SHGetSpecialFolderLocationanbieten.
Nur finde ich keine Aufstellung über die CLIDs, die den Ordner identifizieren.

[Nersgatt]

Schau mal hier: http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx

[f4k3]

Habs auf SwissDelphiCenter.ch gefunden

Die CSIDL lautet:
CSIDL_APPDATA

[f4k3]

Zitat von Nersgatt:

Schau mal hier: http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx

Danke fast zeitgleich