pBibliothek

[OrNEC]

Zitat von Aviator:

Mir ist aufgefallen, dass wenn man die Suche benutzt (mit der Standard DB (Auslieferungszustand)), werden die beiden letzten Spalten verändert und es steht nicht mehr der richtige Wert drin. Ich gehe mal davon aus, dass du dort einfach nur das falsche Feld aus der DB ausliest in dem Moment.

Entliehen wird zu Stehplatz
Stehplatz wird zu Sprache

Wohl den Index 1 zu weit gesetzt oder sowas in der Art.

Stimmt, danke, hab's geändert, ist in der nächsten Version drin!

[Aviator]

Eine andere Frage: Hast du beim SuchEdit die Entf (Del) Taste gesperrt? Finde ich persönlich jetzt nicht so eine sonderlich gute Funktion.

[OrNEC]

Zitat von Aviator:

Eine andere Frage: Hast du beim SuchEdit die Entf (Del) Taste gesperrt? Finde ich persönlich jetzt nicht so eine sonderlich gute Funktion.

Das ist standardmäßig nicht aktiv, muss ich schauen was sich da machen lässt.

[OrNEC]

Hab die Version 0.3 beta hochgeladen!

[Aviator]

Hi,

das mit dem Bild und der Notiz gefällt mir ganz gut. Die Entfernen Taste beim Suchen geht aber immer noch nicht

Ein Problem ist mir noch aufgefallen, wenn man die DB (Database.db - Datei) einfach so weglöscht und das Programm dann startet, dann bringt er noch einen Syntaxerror, da die DB feht. Er erstellt zwar danach wieder alles, nur die Fehlermeldung solltest du vielleicht noch abfangen.

[OrNEC]

Zitat von Aviator:

Hi,

das mit dem Bild und der Notiz gefällt mir ganz gut. Die Entfernen Taste beim Suchen geht aber immer noch nicht

Danke, danke! Jah... muss ich noch machen.

Zitat von Aviator:

Ein Problem ist mir noch aufgefallen, wenn man die DB (Database.db - Datei) einfach so weglöscht und das Programm dann startet, dann bringt er noch einen Syntaxerror, da die DB feht. Er erstellt zwar danach wieder alles, nur die Fehlermeldung solltest du vielleicht noch abfangen.

Stimmt, muss das mal ändern, hab mir aufgeschrieben!

[sx2008]

Wieso speicherst du denn Datumfelder als Datentyp VARCHAR(255)?
SQLite speichert Datum/Zeit in folgenden Datentypen:

Code:

    TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
    REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
    INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Wenn deine SQLite-Komponenten etwas taugen müsste eigentlich die Umwandlung nach TDateTime automatisch erfolgen.

[OrNEC]

Zitat von sx2008:

Wieso speicherst du denn Datumfelder als Datentyp VARCHAR(255)?
SQLite speichert Datum/Zeit in folgenden Datentypen:

Code:

    TEXT as ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").
    REAL as Julian day numbers, the number of days since noon in Greenwich on November 24, 4714 B.C. according to the proleptic Gregorian calendar.
    INTEGER as Unix Time, the number of seconds since 1970-01-01 00:00:00 UTC.

Wenn deine SQLite-Komponenten etwas taugen müsste eigentlich die Umwandlung nach TDateTime automatisch erfolgen.

Sind etwa TEXT und VARCHAR(255) verschieden? Dachte das macht keinen großen Unterschied.

[sx2008]

Aber wenn ich richtig gesehen habe verwendest du das ISO8601 Format nicht.
Ich weiss nicht welche Komponenten du für den Zugriff auf Sqlite verwendest, aber eigentlich sollte dort die Umwandlung zwischen dem Delphityp TDateTime und einem der 3 Formate von Sqlite stattfinden.

Wenn du eines der 3 offiziellen Formate verwendest, dann kannst du auch nach diesen Feldern sortieren.
Das Datum als String wie es in Deutschland üblich ist (18.03.2013) ist ja ohne Umwandlung nicht sortierfähig.