TSQLiteDatabase: A SQLite3 Database Wrapper

[HalloDu]

Entschuldigung das ich mich erst heute wieder melde, hatte recht viel zu tun und das dann über die Arbeit etwas verpennt. Also was dein Problem angeht, so solltest du einfach ein simples Reset vor jedem neuverwenden des Statments aufrufen, dann sollte es gehn. Was die Performance angeht, so ist das Problem, dass wenn du 100 Einträge hinzufügst jedesmal ein Festplattenzugriff gemacht werden muss.

Delphi-Quellcode:

DB.Execute('BEGIN TRANSACTION');
//INSERTS, INSERTS, INSERTS
DB.Execute('END TRANSACTION');

beschleunigt das ganze enorm. (oben Beispiel hinzugefügt)

PS: Was die Interfaces angeht, so bin ich da noch nicht ganz durchgestiegen, es ist aber jeder angehalten, der möchte, sich in diesem Bereich an dem Projekt zu beteiliegen.

[Mithrandir]

Also in meinem Fall so:

Delphi-Quellcode:

procedure TDatabase.AddFile(FileSpecs: TFileSpecs);
  var
    FileCmd: TSQLiteCommand;
  begin
    DB.Execute('BEGIN TRANSACTION');
    FileCmd := fDB.Command('INSERT INTO FILES (FILE_PATH, FILE_EXT, FILE_TITLE, FILE_ARTIST, FILE_ALBUM, FILE_YEAR, FILE_GENRE, FILE_LENGTH) ' +
                        'VALUES ( ? , ? , ? , ? , ? , ? , ? , ? );');
    FileCmd.Binding[1].AsString := FileSpecs.fFilePath;
    FileCmd.Binding[2].AsString := FileSpecs.fFileExtType;
    FileCmd.Binding[3].AsString := FileSpecs.fTitle;
    FileCmd.Binding[4].AsString := FileSpecs.fArtist;
    FileCmd.Binding[5].AsString := FileSpecs.fAlbum;
    FileCmd.Binding[6].AsString := FileSpecs.fYear;
    FileCmd.Binding[7].AsString := FileSpecs.fGenre;
    FileCmd.Binding[8].AsInteger := FileSpecs.fLength;
    FileCmd.Execute;
    FileCmd.Free;
    DB.Execute('END TRANSACTION');
  end;

oder?

[HalloDu]

Das hätte keine Auswirkung auf die Performance. Du musst, wenn du weißt, dass das mehrere Inserts werden werden, diesen Prozess, z.B. eine For-Schleife, mit der Transaktion umgeben, siehe Beispiel oben. Das ist sowieso bei vielen Änderungen in der Datenbank zu empfehlen, und auch bei den meisten Datenbanken machbar. Wenn z.B. ein Problem auftritt, kannst du dann den ganzen Prozess mit einem Rollback wieder rückgängig machen, siehe dazu SQLite Doku

[Mithrandir]

Ah, ok. Und wie genau war das mit dem Reset gemeint?

[xZise]

Ich nehme mal er meinte das so:

Code:

BEGIN TRANSACTION
  INSERT ...
  Schleife:
    Binds ...
    Exec ...
    Reset ...
COMMIT

Achso und warum muss man ".Execute('BEGIN TRANSACTION')" aufrufen? Also ich fand es total unpraktisch und habe es so implementiert, wie bei "BeginUpdate"/"EndUpdate". Weil wenn ich das richtig noch in Erinnerung habe, dann kann man nur einmal "Begin Transaction" aufrufen.

MfG
xZise

[Wormid]

Hallöchen,

gibt es eigentlich eine aktuellere Version des Wrappers? Hat sich daran noch etwas getan?

Gruß

Wormid

[dGeek]

Ich habe mal ein wenig gebuddelt und das Thema hier gefunden.
Ich stelle mir gerade die Frage, ob ich von INI zu SQLite3 umstellen sollte oder eher nicht.

In einer INI-Datei meines Projektes können zwischen 1 und 100 Sektionen sein (in der Regel maximal 10) mit etwa (je nach Sektion) 20 bis 30 Schlüsseln.
Es wird relativ häufig auf die einzelnen Schlüssel zugegriffen. Eigentlich sogar immer - egal, was man bei meinem Projekt macht, wird irgendetwas ausgelesen.

Da stellt sich mir nun die Frage: weiterhin INI oder SQLite3?

[Sir Rufo]

Bau dir eine abstrakte Klasse, wo du die Werte abfragen kannst.

Dann dazu die konkrete für eine Ini-Datei (beim reinen Lesen bietet sich auf jeden Fall TMemIniFile an) und bei Bedarf weitere (die dann z.B. mit einer SQlite DB spricht).

Dann kannst du die auch direkt vergleichen, was dir genehmer ist oder was im konkreten Fall besser passt.

Eine Ableitung von TCustomIniFile die dann mit einer SQlite Datenbank spricht ist natürlich auch denkbar.

[dGeek]

So wie ich das verstanden habe, kann ich also einfach TIniFile durch TMemIniFile austauschen.
Und dort wo gespeichert wird, müsste ich dann UpdateFile aufgerufen werden.

Richtig oder liege ich total falsch?