SQLite und datensensitive Komponenten?

[Sven M.]

@DeddyH: Ob ich die Daten aus der Tabelle abfrage und in die Series schreibe oder erst in ein TClientDataset, das ich dann der Series zuweise, macht im Endeffekt aber keinen Unterschied, oder? Wäre doch eher noch umständlicher?!

Ich werf' mal einen Blick auf die Zeos-Bibliotheken. Danke!

[baeckerg]

Wenn Du XE5 verwendest kannst Du FireDAC verwenden

[Sven M.]

XE 5? Davon kann ich nur träumen. Die Angabe da unter meinem Benutzernamen ist tatsächlich aktuell.

[TraumTaenzerDieter]

Oder du nimmst die Komponenten von dieser Seite
http://www.filedepot.eu/sivak3/index.htm
die auch einen TDataSet enthalten.

[Furtbichler]

Hab mit SQLLite-Komponenten ohne Generics leider nur schlechte Erfahrungen gemacht (Bugs ohne Ende), lasse mich gerne eines Besseren belehren.

Vielleicht doch eine Nummer größer, also FB (embedded) und Zeos o.ä.? FB ist eh mächtiger und auch nicht (viel) komplizierter.

Alternativ kann man auch mit den vielen Text-orientierten TDataset-Derivaten seine ersten Gehversuche starten, das wäre dann ganz ohne DB (einfach mal Torry.net konsultieren)

[Perlsau]

Zitat von Sven M.:

@DeddyH: Ob ich die Daten aus der Tabelle abfrage und in die Series schreibe oder erst in ein TClientDataset, das ich dann der Series zuweise, macht im Endeffekt aber keinen Unterschied, oder? Wäre doch eher noch umständlicher?!
Ich werf' mal einen Blick auf die Zeos-Bibliotheken. Danke!

Den Ausdruck "in die Series schreiben" vestehe ich nicht. Was meinst du damit?

Ich habe letzte Woche an einer Minimalverschlüsselung für eine Projekterweiterung gearbeitet: Weil Firebird 2.5 noch keine Verschlüsselung kennt (soll ja angeblich mit V3.0 kommen), bin ich zur lokalen Bearbeitung der verschlüsselten Tabelle auf ein Clientdataset ausgewichen. Nach einigen Anlaufschwierigkeiten funktioniert das ebenso gut wie irgend ein DBDataset oder eine Query-Komponente. Man darf nur nicht vergessen, beim Start die Daten zu laden und vor Programmende wieder zu speichern. Das Programm PasswortTresor,* quasi ein Abfallprodukt meiner Auftragsarbeit, verwendet diesse Methode. Für SQLite muß man das natürlich anders machen, aber da kennen sich andere besser aus als ich.

Delphi-Quellcode:

// ********** CLIENT-DATASET LADEN *****************
Procedure TDatMod.ClientSet_Laden;
begin
  ClientSet_Zugang.Active       := False;
  Qset_Zugang.Open;
  ClientSet_Zugang.ProviderName := 'Prov_Zugang';
  ClientSet_Zugang.Open;
  ClientSetKodieren(1);
  Dsrc_Zugang.Enabled           := True;
  Qset_Zugang.Close;
  ClientSet_Zugang.ProviderName := '';
end;

// ********** CLIENT-DATASET SPEICHERN *************
Procedure TDatMod.ClientSet_Speichern;
Var
  Idx : Integer;
begin
  Dsrc_Zugang.Enabled := False;
  ClientSetKodieren(0);
  Qset_Zugang.Open;

  ClientSet_Zugang.First;
  WHILE NOT ClientSet_Zugang.Eof DO
  BEGIN
    Idx := ClientSet_Zugang.FieldByName('IDX_ZUGANG').AsInteger;
    IF NOT ClientSetToQuery(Idx) THEN ShowMessage('Fehler beim Speichern des ClientSets: ' + IntToStr(Idx));
    ClientSet_Zugang.Next;
  END;
  Qset_Zugang.Close;
end;

* (Freeware, Benutzer: Admin, Passwort: a1)

[Sven M.]

@TraumtänzerDieter: Das schau' ich mir mal näher an. Besten Dank.

@Furtbichler.
Zeos habe ich auch schon probiert, sollte zumindest theoretisch ja auch mit SQLite funktionieren. Allerdings habe ich das Problem, dass ich in allen heruntergeladenen Archiven nicht ein Package finde, mit dem ich die Komponenten installieren kann. Ich gebe zu: Ich fühle mich deswegen momentan ziemlich minderbemittelt. Denn alle Tutorials, die ich finden konnte, gehen genau davon aus.

@Perlsau:
Hm, doof umschrieben, zugegeben. "TLineSeries mit Werten befüllen" sollte klarer ausdrücken, was ich machen will.
Deine vorgeschlagene Alternative mit den CleintDataSets kommt für mich leider nicht in Frage. Von denen will ich ja gerade weg. Denn da nervt mich, dass jedes Mal die gesamte Datenmenge weggeschrieben wird. Das ist f+r meine Ansprüche einfach nicht pratikabel.

Im Prinzip brauche ich eine simple lokale Datenbank, die es mir ermöglicht, unter Delphi 5 mehrere Tabellen (max. 7-8) mit jeweils ~500.000 Datensätzen abzuspeichern. Schön wäre außerdem eine Anbindung an datensensitive Komponenten (TLineSeries in DBChart) sowie möglichst wenig DB-Gedöns, das ich dem User abseits der Exe noch mitgeben muss. Da dachte ich nun mit der im Startpost erwähnten Komponente die Lösung gefunden zu haben (benötigt nur die dll), allerdings fehlt mir da die Möglichkeit, die Daten direkt in DB-Komponenten anzeigen zu lassen.




+++edit+++
Die von TraumtänzerDieter vorgeschlagenene Komponente funktioniert nicht unter Delphi 5. Nach dem Löschen der vom Compiler nicht erkannten Module vcl, rtl, dbrtl sowie unbekannten Compilerdirektiven (Warn, Align 8), stockt der Compiler bei der Zeile
DefaultFormatSettings: TFormatSettings; TFormatSettings ist ihm nicht bekannt.

[Perlsau]

Zitat von Sven M.:

@Perlsau:
Hm, doof umschrieben, zugegeben. "TLineSeries mit Werten befüllen" sollte klarer ausdrücken, was ich machen will.
Deine vorgeschlagene Alternative mit den CleintDataSets kommt für mich leider nicht in Frage. Von denen will ich ja gerade weg. Denn da nervt mich, dass jedes Mal die gesamte Datenmenge weggeschrieben wird. Das ist f+r meine Ansprüche einfach nicht pratikabel.

ClientDataSets laden und speichern sich nicht von alleine. Du kannst eine Tabelle mit einem ClientDataSet so lange bearbeiten, wie du willst. Bevor das Programm beendet wird, schreibst du den Inhalt zurück, entweder in die Datenbank oder auf die Festplatte oder sonstwohin. Dafür hatte ich mir im PasswortTresor die beiden Methoden geschrieben. Von daher verstehe ich dein Problem mit ClientDataSets nicht.

[sx2008]

Zitat von Sven M.:

Im Prinzip brauche ich eine simple lokale Datenbank, die es mir ermöglicht, unter Delphi 5 mehrere Tabellen (max. 7-8) mit jeweils ~500.000 Datensätzen abzuspeichern. Schön wäre außerdem eine Anbindung an datensensitive Komponenten (TLineSeries in DBChart) sowie möglichst wenig DB-Gedöns, das ich dem User abseits der Exe noch mitgeben muss.

Da würde sich eine Access Datenbank (*.mdb) anbieten.
In D5 Enterprise hast du die nötigen ADO-Komponenten schon an Bord und du vermeidest damit die völlig veraltete BDE.
Auf den Zielrechnern sind in der Regel alle nötigen Treiber (OLE-DB Provider) als Teil des Windows OS schon installiert.
Dies gilt allerdings nicht für Windows 7 und höher aber man kann die Treiber (Jet Engine 8) einfach nachinstallieren.
http://support.microsoft.com/kb/239114/de

Damit kannst du sämtliche datensensitiven Komponenten benützen.
Ausserdem kannst du relativ leicht von MS Access auf MS SQL Server umschalten da die SQL Dialekte eine grosse gemeinsame Schnittmenge haben.
Ein weiterer Vorteil ist dass du als Entwickler mit MS Access eine sehr leistungsfähige Benutzeroberfläche hast um die Datenbank zu administrieren (Tabellen anlegen, Testdaten einfügen/ändern/löschen usw.)

Das Datenbankformat *.mdb und damit die Jet Engine ist inzwischen von MS abgekündigt und wird nicht mehr weiterentwickelt.
Aber über die ADO-Komponenten stehen dir auch viele andere Datenbanken offen (insbesondere MS SQL Server).

[Furtbichler]

Zitat von sx2008:

In D5 Enterprise hast du die nötigen ADO-Komponenten schon an Bord und du vermeidest damit die völlig veraltete BDE.

Ich hätte schwören können, das die bei D5 noch nicht zu gebrauchen waren. Aber da habe ich mich wohl geirrt.