Globale Vriablen, Record´s oder Objecte Konfigurationsdaten

[Jens Hartmann]

Hallo zusammen,

ich habe mal wieder eine Frage, aber ein die für mich keine Lösungsproblem darstellt, sondern vielmehr stelle ich mir die Frage welcher Lösungsweg wohl der richtige wäre.

Ich habe mein Programm eigendlich fertig,(was man so fertig nennen kann).
Jetzt sitze ich zur Zeit davor, den Code anzupassen und gewisse Sachen eventuell einfacher und Übersichtlicher zu lösen.

Mein Problem ergibt sich jetzt dabei, das ich in meiner Datenbank eine Tabelle habe, in der einige (ca. 25) Einstellungsparameter gespeichert sind. Diese nutze ich für z.B. USER Rechte, Systemkoniguration etc.

Beim Start von meinem Programm, und in verschiedenen Funktionen, benötige ich jetzt diese Werte
(String´s, Integer und Boolean(als Integer 0/1).

Daher meine Frage: 1. Lese ich alle Parameter direkt beim Programmstart ein oder immer dann wenn ich Sie benötige.
2. Wenn ich die Parameter einlese, trage ich diese direkt in Ihrer Komponenten ein, die allerding auf verschieden Formen positioniert sind, oder lese ich die Parameter z.B. in Globale Variablen, Record´s oder Objecte.
3. ....?

Naja so könnte man jetzt fortfahren, Also meine gezielte Frage: Wie geht man sowas mit solchen Parametern(Einstellungen) an.

Gruß Jens

[SimStar001]

Also ich würde die Einstellungen zum Programmstart laden, dann hast du später keine Ladezeiten. Kommt aber immer drauf an, wie oft du mit den Einstellungsparametern arbeiten musst, damit es sich lohnt das beim Programmstart zu tun.

Was das Speichern betrifft, kommts halt auch wieder drauf an was du damit machen willst, verrat doch einfach mal mehr!

[mkinzler]

Benutzt du ein Datenmodul?

[Elvis]

3. Du hälst an allen stellen eine Referenz auf deinen ConfigManager oder wie er bei dir auch heißt.

Den könntest du bereits in der DPR erzeugen und an das erste Form und andere Objekte, die dort erzeugt werden übergeben.
Wenn du Code nur in Forms liegen hast und/oder dein Hauptform in seinem ctor oder FormCreate deinen Initialisierungs-Code hat, dann könntest du es auch dort erzeugen.
Wichtig ist halt, dass du die Referenz an alle Objekte weitergibst, die du anlegst.
Globale Funktionen wären hier natürlich Shy-C, aber das sind sie sowieso. ;-)
Wenn du deine Logik, die mit den Config-Daten arbeiten musst schön in Instanzmethoden von Klassen stehen hast, kannst du diesen Klassen einfach eine Referenz mitgeben.
Globale Referenzen sind ziemlich beschissen, was Skalierung oder spätere Änderungen angeht.
Es kann ja gut sein, dass du einen 2. Satz von Configs haben willst, der während des Editierens "lebt" und wenn der User diesen 2. Satz testen will, will er ja nicht den richtigen Satz Configs zerlegen. Für alle Fenster/Worklflows, die nix mit dem Testen der neuen Config zu tun hätten, sollte ja weiterhin der richtige satz von Werten gelten können.
Oder wenn du einen Thread startest, willst du dem vllt eine kopie der aktuellen Settings mitgeben. So kann der seine Aufgabe erledigen ohne a) ständig alle Zugriffe auf die Config mit Criticalsections zu sperren (und gesperrt zu werden) und b) würde er konsistent mit dem gleichen Satz von Anfang bis Ende arbeiten.

Wenn du globale Variablen benutzt, kannst du sowas schlicht und ergreifend vergessen.

@Datamodule: Die Viecher sind doch auch nur globale Variablen.
Rein vom Code design her, wären Datamodules höchsten zu gebrauchen um von der Configklasse instanziert zu werden damit dort einige Logik visuell zusammengeklickt werden kann. (Also 2-10 Minuten Code eingespart, dafür X Abhängigkeiten und Points of Failure gewonnen)
Aber unterm Strich bringen DMs fast gar nix.

[Jens Hartmann]

Zitat:

Zitat von SimStar001

Was das Speichern betrifft, kommts halt auch wieder drauf an was du damit machen willst, verrat doch einfach mal mehr!

Also, das sind alles Variablen, die ich in verschiednen Formen einstellen kann. Mein Programm kann z.B. automatisch E-Mail´s über SMTP Server versenden. In einer Form siehe Anhang, kann man das halt konfigurieren. Momentan, habe ich einfach die Werte fest als EDIT.Text in der Entwurfszeit eingetragen, um die Funktionen Funktionen zu testen. Mittlerweile, habe ich allerdings diese ganzen Daten in einer Datenbank, und diese Wert auch schon über Speicherfunktonen dort hinterlegt.

Alle anderen Einstellungen, habe eigendlich den selben Sinn. Parameter der COM-Schnittstelle, Berechtigungsklassen(welche Button, Menü´s etc,) welcher angemeldete USER nutzen will, oder überhaupt erst darf.

Also im Grundegenommen, die üblichen Einstellungen in einen Programm OPTIK und FUNKTION.

Zitat:

Zitat von mkinzler

Benutzt du ein Datenmodul?

Zur Zeit noch nicht. Momentan, befinden sich meine Connection und Query Komponenten auf den jeweiligen Formen, ich will das aber eigendlich irgendwann mal umstellen. Nur am Anfang, wusste ich noch nicht genau wie das geht, und daher momentan ohne Datenmodul.

Gruß Jens

[EDIT]

Zitat:

Zitat von Elvis

@Datamodule: Die Viecher sind doch auch nur globale Variablen.
Rein vom Code design her, wären Datamodules höchsten zu gebrauchen um von der Configklasse instanziert zu werden damit dort einige Logik visuell zusammengeklickt werden kann. (Also 2-10 Minuten Code eingespart, dafür X Abhängigkeiten und Points of Failure gewonnen)
Aber unterm Strich bringen DMs fast gar nix.

Das z.B. ist für mich schon wieder eine ganz neue Ansicht. Allerdings, gebe ich zu, das ich von dem Rest was du geschrieben hast, nicht alzu viel verstanden habe. Das muss ich mir erst nochmal in Ruhe durchgehen.

Gruß Jens

[Chemiker]

Hallo Jens,

die Daten für die COM-Schnittstelle und der Datenbank lege ich als INI-Datei ab. Beim Start des Programms wird danach gesucht und entweder sie sind vorhanden, oder sie werden neu angelegt.

Bis bald Chemiker

[Luckie]

Wenn man einen Wert aus einer anderen Form braucht, dann übergibt man den Wert an die Form beim Erzeugen als Property:

Delphi-Quellcode:

unit Unit2;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm2 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
    FMeinText: String;
  public
    { Public-Deklarationen }
    property MeinText: String read FMeinText write FMeinText;
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}

procedure TForm2.Button1Click(Sender: TObject);
begin
  ShowMessage(FMeinText);
end;

end.

Delphi-Quellcode:

uses
  Unit2;

procedure TForm1.Button1Click(Sender: TObject);
var
  ZweiteForm: TForm2;
begin
  ZweiteForm := TForm2.Create(nil);
  try
    ZweiteForm.MeinText := 'Dieser Text kommt aus Form1';
    ZweiteForm.ShowModal;
  finally
    ZweiteForm.Free;
  end;
end;

[Reinhard Kern]

Hallo Jens,

eine mögliche Art, das mit einer Klasse anzugehen (die wird für jedes Programm benötigt und beruht auf einer Klassenhierarchie, die allen gemeinsam ist):

Delphi-Quellcode:

{ Deklaration }
  type

  TBPMLogSettings = class (TRKIniSettingTable)
    public
    Station_Node        : TRKiniSettingValue; { group }
    Station_Description : TRKiniSettingValue; { group }
    Station_CommPort    : TRKiniSettingValue; { group }
    Station_USBSerial   : TRKiniSettingValue; { group }
    QSDoc_Path          : TRKiniSettingValue;

.....

{ Create }
constructor TBPMLogSettings.CreateTable (IC : TRKIniClass);
var CSection : ShortString;

begin
inherited Create (IC);

with BLMainForm do
  begin
  CSection := 'Station';
  Station_Node       := TRKiniSettingValue.Create_Integer (-maxStationNo,CSection,
        'Node',0, [] ,self);
  Station_Description  := TRKiniSettingValue.Create_String (-maxStationNo,CSection,
        'Description','', [] ,self);
  Station_CommPort   := TRKiniSettingValue.Create_Integer (-maxStationNo,CSection,
        'CommPortNumber',0, [] ,self);
  Station_USBSerial  := TRKiniSettingValue.Create_String (-maxStationNo,CSection,
        'USBSerial','', [] ,self);
  QSDoc_Path            := TRKiniSettingValue.Create_String (1,'QS-Doc',
        'Path','', [] ,self);

....

{ Wert holen }
fTimeBase := BPMLogSettings.Station_TimeBase.GetInteger (1);

Erklärung:

Es gibt für jedes Programm eine Klasse XYZLogSettings, in der ein Parameter als TRKiniSettingValue deklariert wird. Im Konstruktor dieser Klasse wird durch einen Create-Aufruf für jeden Parameter festgelegt, um was für einen Type es sich handelt (Bool,Integer,Real,String,Binary,Windowposition,Fo nt,Color...), welcher Default und wenn möglich auch (vorletzter Parameter) Controls zum Lesen und Schreiben, für die meisten Typen ein array of TEdit.

Im Regelfall ist das meiste damit erledigt: Alles was in XYZLogSettings deklariert ist, kann am Programmbeginn mit ReadAllValues gelesen werden, und geänderte Werte werden am Programmende mit SaveAllValues in die Ini-Datei oder Registry zurückgespeichert.

Das mit den Gruppen ist noch eine weitere Arbeitserleichterung: mit dem Wert 10 werden 10 Werte definiert nach dem Muster Section - Key1 - Key2 ... Key10, mit dem Wert -10 nach dem Muster Section1 - Key, Section2 - Key usw. einfache Werte haben eben eine 1.

Es gibt natürlich noch viel mehr Möglichkeiten, aber das gehört nicht hierher.

Gruss Reinhard

[Chemiker]

Hallo,

wenn man ein Datenmodul benutzt kann man zum Beispiel das Speichern und Laden der INI-Datei im Datenmodul unterbringen.

Delphi-Quellcode:

procedure TDM.DataModuleCreate(Sender: TObject);
var
  Test: Boolean;
  DBVerbindungsDaten: TDBVerbindungDaten;
  aInitDateiName: TFileName;
begin
  IniPathName(aInitDateiName);   
  if not FileExists(aInitDateiName) then
  begin
    // Es besteht keine Verbindung zur Datenbank
    TfrmDatenBankVerbinden.GetData1 (Test, DM.SPSDAPDataBase,
                                 DM.SPSDAPDataSet, DM.SPSDAPTransactionPruefen);
  end else
  begin
    DBVerbindungsDaten:= TDBVerbindungDaten.Create;
    try
      DBVerbindungsDaten.DBDatenIniLesen(aInitDateiName);
      DM.SPSDAPDataBase.DBName:= DBVerbindungsDaten.DBPathName;
      DM.SPSDAPDataBase.LibraryName:= DBVerbindungsDaten.FBLibaray;
      DM.SPSDAPDataBase.ConnectParams.UserName:= DBVerbindungsDaten.DBNutzer;
      DM.SPSDAPDataBase.ConnectParams.Password:= DBVerbindungsDaten.DBPasswort;
    finally
      DBVerbindungsDaten.Free;
    end;
  end;

beim Verlassen des Programms werden die aktuellen Verbindungsdaten wieder in die INI-Datei geschrieben.

Delphi-Quellcode:

procedure TDM.DataModuleDestroy(Sender: TObject);
var
  DBVerbindungsDaten: TDBVerbindungDaten;

  aInitDateiName: TFileName;
begin
  IniPathName(aInitDateiName);
  DBVerbindungsDaten:= TDBVerbindungDaten.Create;
  try
    DBVerbindungsDaten.DBPathName:= DM.SPSDAPDataBase.DBName;
    DBVerbindungsDaten.FBLibaray:= DM.SPSDAPDataBase.LibraryName;
    DBVerbindungsDaten.DBNutzer:= DM.SPSDAPDataBase.ConnectParams.UserName;
    DBVerbindungsDaten.DBPasswort:= DM.SPSDAPDataBase.ConnectParams.Password;
    DBVerbindungsDaten.DBDatenIniSchreiben(aInitDateiName);
  finally
    DBVerbindungsDaten.Free;
  end;

Damit das ganze Funktioniert muss in der Project-Datei die Datei als erstes stehen:

Delphi-Quellcode:

program SPSDAP2009;

uses
  uDatenBankVerbindung in 'SPSDAP-Datenbank\uDatenBankVerbindung.pas' {frmDatenBankVerbinden},
  uSPSDAPDM in 'SPSDAP-Datenbank\Datenmodul\uSPSDAPDM.pas' {DM: TDataModule},

usw.

Außer für die Forms habe ich im gesamten Programm keine globale Variablen.

Bis bald Chemiker

[Jens Hartmann]

Hhmm, ist jetzt doch echt komplizierter als ich dachte. Ich glaube ich versteh das noch nicht so ganz. Ich habe die Daten, die zur Nutzung des Programm´s notwendig sind, ja eigendlich vor in eine Datenbank zu implementiern, bzw ich habe das so schon gemacht. Jetzt wird hier schon wieder von INI-Dateien, Registry etc. geredet, so wie ich es ja zum Teil schon programmiert habe.

Meine Einstellungen für die COM-Schnittstelle liegen momentan in der Registry, meine Kundeninformationen in einer verschlüsslten Textdatei, die Einstellungen für E-Mail und Oberflächen Gestaltung mache ich momentan manuell über die Entwurfszeitkomponenten, wie TEdit.Text. Die restlichen Parameter wie Hardwareanpassung(Zentralenverwaltung etc.) liegen in einer INI-Datei gespeichert.

Wenn ich diese Informationen jetzt benötige, frage ich die wie folgt ab...

Delphi-Quellcode:

  Einstellungen := TIniFile.Create(C:\Programe\HU\Print&Save\Einstellungen.Ini');
  with Einstellungen do begin
    ConfigComForm.CBAutoAufzeich.Checked := ReadBool('Einstellung','Automatische Aufzeichnung', false);
    ConfigComForm.CBSystemstart.Checked := ReadBool('Einstellung', 'Automatischer Programmstart', false);
    ConfigComForm.RGZentralentyp.ItemIndex := ReadInteger('Einstellung', 'Zentralentyp', 0);
  end;
  Einstellungen.Free;}

  ComPort1.LoadSettings(stRegistry, 'HKEY_LOCAL_MACHINE\Software\HU\PRINTSAVE');
  Pfad:=ExtractFilePath(Application.EXEName);

Jetzt muss ich zugeben, das ich ein bißchen überfordert bin. Weil meine Gedanken, gingen eigendlich dahin, das ich alle Einstllungen und Parameter sowie Informationen, in meiner Datenbank integrieren wollte, und diese daraus Abfrage.

Gruß Jens

[Chemiker]

Hallo Jens,

das Du die Daten in eine Datenbank ablegst ist ja erst mal OK, aber bevor Du Zugriff auf die Datenbank herstellen kannst sind ja gewisse Daten notwendig und diese Daten lege ich in eine INI-Datei ab.

Bis bald Chemiker

[Jens Hartmann]

Zitat:

Zitat von Chemiker

das Du die Daten in eine Datenbank ablegst ist ja erst mal OK, aber bevor Du Zugriff auf die Datenbank herstellen kannst sind ja gewisse Daten notwendig und diese Daten lege ich in eine INI-Datei ab.

Was für Daten meinst Du?

Z.B. den Speicherort der Datenbank. Den habe ich über einen Alias realisiert, der in der Aliases.conf von Firebird abgelegt ist. Ansonsten, habe ich eigendlich keine Daten die ich vorher benötige.

Gruß Jens

[Christian Seehase]

Moin Jens,

also ich mache das, i.d.R., so ähnlich wie Reinhard.
Jedes Programm hat ein Settings-Objekt, dass dann im Hauptform erzeugt und von da aus dann zur Nutzung an andere Formulare/Funktionen/Objekte weitergegeben wird (so ähnlich wie Luckie es beschrieben hat).
Wo die Daten dann tatsächlich liegen, spielt dann keine Rolle mehr, da es für das Programm völlig transparent ist.
Man kann eine Datenbank, eine ini, die Registry oder was einem sonst noch so einfällt verwenden.
Unter Verwendung eines Parameters (ggf. auch mehrere), die angeben, wo die Konfiguration liegt, kann man dann auch problemlos verschiedene Konfigurationen ermöglichen (z.B. Userspezifisch)
Ob man die Daten dann einmal einliest, oder immer jeweils direkt aus der Konfiguration ausliest hängt auch davon ab, ob nach dem Programmstart Änderungen erlauben will oder darf.
Analog ist es dann auch mit dem Ändern der Konfigurationsdaten.
Es hängt vom Zusammenhang ab, ob man solche Änderungen erst beim Programmende, oder gleich bei jeder Änderung wegschreibt.

[Jens Hartmann]

Hallo Christian,

also momentan, schreibe ich die Konfiguationen sofort, weil ich ja, je nach Hardware andere Parameter benötige.
Die Parameterabfrage, mache ich momentan, dann bei jedem Ablauf, allerings, direkt aus den Konfigurationskomponenten.

z.b. so..

Delphi-Quellcode:

            case Hardwareanbindung.RGZentralentyp.ItemIndex of
              0 : DatenverarbeitungMB24;
              1 : DatenverarbeitungMB48;
              2 : DatenverarbeitungMB100;
              3 : DatenverarbeitungMB256;
              4 : DatenverarbeitungUEZ2000;
              5 : DatenverarbeitungBMC1024;
            end;

die case Anweisung fragt eine RadioGroup ab, diese wird bei Programmstart über eine IniDatei, Sorry mittlerweile über die DB geladen, und nach einer Änderung auch sofort in der DB gespeichert.

Bei dem Programmablauf, frag ich halt nicht die DB ab, sondern direkt die Komponenten. Wenn das ja so OK wäre, muss ich das ja eigendlich nur noch alles von INI auf DB umstellen, und fertig. Die frage, die ich mir gestellt habe, war allrdigs, ob das so in Ordnung ist.

Gruß Jens

[Reinhard Kern]

Zitat:

Zitat von Jens Hartmann

Bei dem Programmablauf, frag ich halt nicht die DB ab, sondern direkt die Komponenten. Wenn das ja so OK wäre, muss ich das ja eigendlich nur noch alles von INI auf DB umstellen, und fertig. Die frage, die ich mir gestellt habe, war allrdigs, ob das so in Ordnung ist.

warum sollte das nicht ok sein, ich mache das genauso, bei mir steht die Settingsklasse mit den einzelnen Settings zwischen der INI-Datei/Registry und der Anwendung, die Anwendung sollte garnicht direkt auf eine Datei zugreifen. Wenn ich dann noch beim Create angebe, welches TEdit zuständig ist, brauche ich das Konfigurations-GUI nur noch zu zeichnen, die Werte stehen dann beim Start automatisch drin und werden auch dort wieder geholt und zurückgespeichert. Allerdings habe ich beim Lesen noch einen Mode-Parameter eingeführt, der angibt, ob der Wert direkt aus dem Setting genommen wird, ob vorher der neueste Wert aus der INI geholt wird und ob der geholte Wert ins TEdit übernommen werden soll. Braucht man aber nicht oft, weil das Setting-Objekt immer den aktuellen Wert hat und sich an der INI eigentlich nichts ändern kann, es sei denn, jemand schreibt hintenrum manuell was rein und es muss sofort übernommen werden - finde ich eher sinnlos.

Wo das Zeug physikalisch gespeichert wird, sollte man so flexibel wie möglich handhaben (ich unterstütze z.B. auch unixartige Home-Verzeichnisse), weil sich das abschliessend sowieso nicht entscheiden lässt: wer MS-hörig ist MUSS die Registry verwenden, INI-Dateien sind transparenter, werden aber vom MS abgelehnt. Datenbanken sind eigentlich zu aufwendig dafür und XML biete auch keine besonderen Vorteile. Ich finde die Tatsache, dass bei Datenbanken die Feldgrösse i.a. festgelegt ist, eher hinderlich, und man muss wohl boolean, integer, real usw. als Strings speichern, wenn man nicht gleich alles als Variant deklarieren will. Das ist allerdings in einer INI auch nicht anders, nur mit freier Stringlänge.

Gruss Reinhard

[Jens Hartmann]

Naja, hört sich doch für mich alles gar nicht so schlecht an. Dann habe ich ja doch irgendwo aufgepasste. Gut aber eins würde mich mal interessieren. Ist es wichtig z.B. nur die Registry oder nur eine INI oder Datenbank zu nehmen. Oder ist es egal, wenn ich diese Daten verteilen tue.

Meiner Meinung nach, sollten die Daten schon alle an einer gemeinsamen Stelle liegen. Wie soll ich sonst noch als USER einen Überblick behalten.

Gut der ein oder andere mag ja jetzt sagen, damit hat der USER ja nichts zu tun. Mag auch stimmen. Aber bei meiner Software z.B. ist es so, das manche USER schon gewisse Kenntnisse mitbringen, und gegebenenfall´s solche Sache wünschen, um solche Einstellung vor dem Programmstart zu realisieren, oder um z.B. bei gemeinsamen Objekten die INI Datei oder so, kopieren zu können, um beim nächsten Objekt diese wieder nutzen zu können.

Daher würde mich Euere Meinung mal interesieren.

Gruß Jens

[Reinhard Kern]

Zitat:

Zitat von Jens Hartmann

...Gut der ein oder andere mag ja jetzt sagen, damit hat der USER ja nichts zu tun. Mag auch stimmen. Aber bei meiner Software z.B. ist es so, das manche USER schon gewisse Kenntnisse mitbringen, und gegebenenfall´s solche Sache wünschen, um solche Einstellung vor dem Programmstart zu realisieren, oder um z.B. bei gemeinsamen Objekten die INI Datei oder so, kopieren zu können, um beim nächsten Objekt diese wieder nutzen zu können.
...

Hallo Jens,

das ist nicht nur Auffassungssache, sondern hängt auch von Zweck und Einsatz der Software ab. Für mich ist ein PC mit meiner Software ein technisches Gerät in einer chemischen Fabrik, und jeder Bediener sollte die gleiche Oberfläche sehen. Fräsmaschinen lassen sich ja auch nicht userspezifisch konfigurieren. Ausserdem habe ich als Netzwerkverwalter genügend schreckliche Erfahrungen gemacht, etwa wenn manche User unbedingt violette Schrift auf grünem Hintergrund einstellen müssen.

Daher musst du dich erstmal entscheiden, ob du Parameter unter HKEY_CURRENT_USER abspeicherst oder HKEY_LOCAL_MACHINE oder teils-teils, und für INI-Dateien, DBs und XML ist das ähnlich: "Eigene Dateien" oder ein gemeinsames Verzeichnis.

Ich halte das schon deswegen flexibel, weil in Grossfirmen mit zehntausenden PCs im Netz ganz wesentlich die Admins entscheiden, wo ich was speichern darf. Die müssen mir dann natürlich auch die Rechte dafür einrichten.

In unserer eigenen Firma habe ich sowieso local und public INIs eingerichtet - die Fensterposition etwa ist lokal, Einstellungen für Drucker dagegen auf einem zentralen Server, schliesslich sollen Rechnungen ja überall gleich rauskommen.

Gruss Reinhard

[Christian Seehase]

Moin Jens,

also ich für meinen Teil bevorzuge für die Konfiguration schlicht Textdateien, meist in der Form von INI-Dateien.
Für anwendungsspezifische Daten kommen diese in ein Verzeichnis unter \Dokumente und Einstellungen\All Users\Anwendungsdaten\ (ggf. noch eine Ebene mehr), für userspezifsche Daten in ein Verzeichnis unter \Dokumente und Einstellungen\<USERNAME>\Anwendungsdaten.

[Jens Hartmann]

Das hört sich doch ganz gut an.

Also, fasse ich mal zusammen,

Ich schreibe meine ganzen Einstelllungsparameter in meine DB, die ja über einen Alias angebunden ist. Wenn ich das so realisierte habe, lese ich die Daten nach Programmstart ein, und habe diese dann somit zur Verfügung.

Nehme ich Änderungen während des Programmablaufes vor, Speicher ich diese in der DB, aber dadurch das ich im Programm den direkten Zusand der Komponente abfrage,kann ich diese Funktion auch sofort nutzen.

Für Sinnvoll halte ich dann eigendlich nur, meine Datenbank zu teilen. Momentan steht ja alles in einer DB, wenn ich aber die Möglichkeit geben will, diese zu kopieren, um diese Einstellungen auf anderen Rechner nutzen zu können, so will ich ja nur die USER Einstellungen oder Grafik-Einstellungen kopieren, und nicht die Datensätze aus Object XY.

Dann werde ich mich jetzt mal damit beschäftigen.

Also schon mal vielen Dank an alle und schöne Ostertage. :thumb:

Gruß Jens

[Chemiker]

Hallo Jens,

die Zugangsdaten sollten meiner Meinung nach, außerhalb der Datenbank anlegen werden. Zum Beispiel der Path der Datenbank, sonst hast Du nach Änderungen des Systems (Path-Änderungen am Server zum Beispiel) keine Möglichkeit aus Deinem Programm heraus diese Änderungen nachzuvollziehen.

Bis bald Chemiker

[Jens Hartmann]

Mag sein, allerdings glaube ich eine etwas andere Anforderung zu haben.
Ich hab mal im Anhang ein Schaubild hinterlegt, der das ganze mal zeigt.

Im Grunde genommen werde ich nie auf das Problem, mit schreibrechten und ändern des Datenpfad´s stoßen. Weil wir die Systemvorraussetzungen festgelegt haben. Aus Siicherheitsgründen werden die PC´s in der Technik integriert.

Es wird in der Einbruchmeldeanlage(EMA) oder Brandmeldeanlage(BMA), ein von uns gelieferter oder vom Kunden zur Verfügung gestellter mini PC installiert. Dieser ist im Gehäuse der EMA oder BMA integriert, und verfügt über zwei Festplatten und Administratorrechte, damit wir als Errichter auch die Möglichkeit besitzen, diesen zu pflegen, und nicht wegen jedem SoftwareUpdate oder so einen Hauseigenen Admin benötigen. Dieses ist auch so mit einem unserer Hauptkunden abgesprochen.

Dieser PC kommuniziert eigendlich nur Stand Alone mit der EMA oder BMA und es soll nur die Möglichkeit bestehen, das dieser PC bei gewissen Ereignissen den Objektmanager z.B. über E-Mail informiert, und das dieser dann die Möglichkeit hat, sich auf den PC einzulogen, und diese Ereignisse dann zu lesen.

Momentan werden wir das halt mit Remotdesktop zur Verfügung stellen.
Es soll allerdings später mal eine Software geben die der Objektmanager besitzt, in der er über Eingabe der Verbindungsdaten
(z.B. Objekt-IP) das jeweilige Objekt erreichen kann, diese Datenbank downloaden kann, und dann auf seinem Arbeitsplatz auswerten kann.


Gruß Jens

[EDIT]Anhang zugefügt

[Chemiker]

Hallo Jens,

wenn keine Änderungen von außen möglich sind, ist es OK.

Bis bald Chemiker

[Jens Hartmann]

Hab den Anhang mal noch angehangen, den ich eben vergessen habe.

Die Vorstellung mit so einer Client-Software, müsste aber doch realisierbar sein. Ich weiß, dafür müsst ich eine neues Thema aufmachen, will ich aber noch gar nicht, weil ich ja erstmal meine Software komplett fertig haben möchte.

Nur vom Gedanke halt, weil sonst, würde sich ja gegebenfalls meine Datenstruktur auch ändern müssen.

Gruß Jens