Table nach Datum filtern

[jedi]

Ich habe nun seit mehreren Tagen gesucht, die gefundenen Beispiele ausprobiert und keine Lösung gefunden,
obwohl dieses Thema schon oft behandelt wurde.

Ich will eine Mitglieder-Datenbank anhand des Geburtstages in Erwachsene und Jugendliche filtern.
Das entsprechende Feld in der Tabelle habe ich mit

Code:

FieldDef.Add('Geb-Tag'), ftDate, 0, False)

angelegt. Vorhandene Testdaten sind Geburtstage 02.04.1950, 03.08.1997 und als Test ein Geburtstag in der Zukunft 05.06.2013.
Wenn ich die Daten über einen Filter ansprechen will, schlägt alles gefundene fehl.
Die einzige Version, die bei mir funktioniert, ist

Code:

MitgliederTable.Filter := 'Geb_Tag = Date()'  // oder
MitgliederTable.Filter := 'Geb_Tag < Date()'  // oder
MitgliederTable.Filter := 'Geb_Tag > Date()'

Hier wird alles richtig ausgewertet und die Auswahl vor bzw. nach Date() auch richtig ausgeführt.

Nun muss ich aber statt Date() ein direktes bzw. errechnetes Datum einsetzen, und da liegt das Problem:

Code:

MitgliederTable.Filter := 'Geb_Tag = 01.01.1995'  // Syntaxfehler in Zahl in Abfrageausdruck 'Geb_Tag = 01.01.1995' aufgetreten
MitgliederTable.Filter := 'Geb_Tag = 01/01/1995'  // keine Datensätze, ist i.O.
MitgliederTable.Filter := 'Geb_Tag < 01/01/1995'  // keine Datensatz
MitgliederTable.Filter := 'Geb_Tag > 01/01/1995'  // Anzeige 3 Datensätze

Wer kann mir helfen bzw. wo liegt der Fehler in meiner Denkweise und wie könnte eine Lösung aussehen?

Danke für Eure Hilfe

[p80286]

Wenn man mit ACCESS direkt arbeitet wird das Datum von # eingeschlossen also

Code:

Gebdatum=#01.01.2012#

versuch es doch einmal so.

Gruß
K-H

[jedi]

Danke, aber Fehlermeldung:

Syntaxfehler in Datum in Abfrageausdruck 'Geb_Tag < #01.01.1994#' aufgetreten.

Nach Umstellung auf: 'Geb_Tag < #01/01/1994#' funktioniert alles!

Nachmals besten Dank!

[sx2008]

Man sollte Felder nicht im Sourcecode mit FieldDef.Add() anlegen, sondern entscheidend ist, dass das Feld in der Tabelle mit dem richtigen Datentyp vorhanden ist und die Testdatensätze entsprechend befüllt sind.

Dann sollte man auf keinen Feld Feldnamen mit Bindestrich ('Geb-Tag') verwenden, weil das als Minuszeichen interpretiert werden kann. Unterstriche sind dagegen in Ordnung.

Datumswerte im Filter-Property sind immer etwas tricky weil man das Datum als String angeben muss und die Schreibweise von den lokalen Einstellungen und/oder von den Eigenheiten der Datenbank abhängt.
Die Schreibweise mit den beiden # ist spezifisch für MS-Access und funktioniert z.B. nicht beim MS SQL-Server.

Wenn man das Event OnFilterRecord benützt, dann kann man sich diese Unsicherheit sparen:

Delphi-Quellcode:

procedure TForm1.MitgliederTableFilterRecord(DataSet: TDataSet; var Accept: Boolean);
var
  d : TDateTime;
begin
  d := SysUtils.Date - 18 * 365; // grob 18 Jahre in die Vergangenheit
  if DataSet.FieldByName('Geb_Tag').AsDateTime >= d then
     Accept := True
  else
     Accept := False
end;

[jedi]

@SX2008
Danke für die Hinweise, eine Frage dazu:

Anlegen der Tabelle:

Code:

FieldDefs.Add()

verwende ich, da jährlich automatisch eine neue Tabelle vom Programm erzeugt werden muss (Anwender hat kein Access).
Danach werden nur ausgewählte Daten der alten Tabelle an die neue Tabelle übergeben, da Informationen über Beiträge u.ä. jahresbezogen
erfasst werde.
Welche (besseren) Möglichkeiten zum Anlegen der Tabellen gibt es?

Bindestrich - Unterstrich ist mir bekannt. Ich verwende generell Unterstriche.

Code:

OnFilterRecord

werde ich mir mal genauer ansehen, habe ich bisher kaum verwendet.
Die Anwendung könnte mir einige Zeilen Quelltext sparen!

[Bernhard Geyer]

Zitat von sx2008:

Wenn man das Event OnFilterRecord benützt, dann kann man sich diese Unsicherheit sparen

Und sich dann wundern wieso die Anwendung so langsam ist. Da der Filter Lokal ausgeführt wird werden alle Daten der Tabelle zum Client übertragen und ausgewertet. Bei einer Tabelle mit 5 GB an Datenvolumen kann es Dauern obwohl Index vorhanden ist und nur wenige Datensätze passen.

Sinnvoll ist es hier sich mit SQL vertraut zu machen. Diese als SQL-Statement mit parameter zu implementieren ist schnell und auch noch relativ unabhängig vom DBMS.

[sx2008]

Zitat von Bernhard Geyer:

Und sich dann wundern wieso die Anwendung so langsam ist. ... Sinnvoll ist es hier sich mit SQL vertraut zu machen.

Ich wollte den TE nicht gleich überfordern.
Eine parametrisierte SQL-Abfrage ist technisch sicher die schnellste und sauberste Lösung.
Wobei, wie viele Mitglieder kann so ein Verein schon haben? Bei < 1000 Mitgliedern ist so ein lokaler Filter kein Problem.

Zitat von jedi:

Welche (besseren) Möglichkeiten zum Anlegen der Tabellen gibt es?

Also normalerweise legt man in der Anwendung keine Tabellen an, sondern man gibt eine leere Datenbank, die aber schon alle Tabellen enthält bei der Installation mit der Anwendung mit.
Man sollte die Datenbank so bauen, dass die Struktur der Tabellen, Felder, Views usw. sich möglichst nicht mehr ändert.

Wenn man z.B. Mitgliedsbeträge pro Jahr erfassen möchte, dann legt man nicht für jedes Jahr eine neue Tabelle an, sondern man speichert alles in einer Tabelle:

Code:

MitgliedNr | Jahr | ZahlDatum
==============================
          1| 2012 | 13.01.2012
          2  2012 | 25.02.2012
          3| 2012 | 08.05.2012
          2| 2013 | 19.02.2013
          3| 2013 | 29.12.2012

Wie man sieht hat Mitglied 1 für das Jahr 2013 noch nicht bezahlt.
Wenn man z.B. wissen möchte, wer im aktuellen Jahr noch nicht gezahlt hat, dann muss man die Betragstabelle mit der Mitgliedertabelle verknüpfen.
Spätestens jetzt kommt man nicht drumrum, sich in SQL einzuarbeiten.

SQL-Code:

-- hole alle Datensätze aus der Mitglieds-Tabelle für die es keinen passenden Datensatz
-- in der Betrags-Tabelle gibt und berücksichte dabei nur das Jahr 2013
SELECT MitgliederTable.* FROM
MitgliederTable
WHERE NOT EXISTS (SELECT * FROM BeitragsTable WHERE BeitragsTable.MitgliedsNr=MitgliederTable.MitgliedsNr AND BeitragsTable.Jahr=2013)

[Bernhard Geyer]

Zitat von sx2008:

Ich wollte den TE nicht gleich überfordern.

Ok. Genehmigt.

Zitat von sx2008:

Eine parametrisierte SQL-Abfrage ist technisch sicher die schnellste und sauberste Lösung.
Wobei, wie viele Mitglieder kann so ein Verein schon haben? Bei < 1000 Mitgliedern ist so ein lokaler Filter kein Problem.

In meiner Access-Vereinsdatenbank lege ich für obige Anforderungen immer Views an die ich dann verwende.

[jedi]

@SX2008

An die Möglichkeit mit einer verknüpften Tabelle zu arbeiten hatte ich in am Anfang auch angedacht, bin aber aus folgendem Grund davon abgekommen:
Die Mitgliederanzahl des Vereinsliegt bei ca. 280 - 300. Die Tabelle der Mitglieder besteht aus 16, die der jahresbezogenen Daten aus 14 Feldern. Im ersten jahr habe ich also 2 Tabellen mit je ca. 300 Datensätzen. Im den folgenden Jahren erweitert sich die Tabelle der jahresbezogenen Daten um jeweils weitere 300 Datensätze, so dass nach wenigen Jahren ein enormer Zuwachs an Daten anfällt, der zu längeren Zeiten bei der Auswertung führen könnte. Das war mein Denkansatz. Wenn der falsch ist, nehme ich gern andere Vorschläge an. Ich arbeite mich ja auch erst noch in die Programmierung ein.

[jobo]

Man würde niemals "gleiche" Daten in verschiedenen Tabellen sammeln. Das sind grundlegende Fragen des Datenbank Designs (Stichwort Normalisierung).
Was sind nun gleiche Daten?
Bspw. wäre es falsch Vereinsmitglieder in 2 Tabellen "JUGENDLICHE" und "ERWACHSENE" zu speichern, vielleicht noch eine 3. Tabelle "ELTERN" (keine Mitglieder). Statt dessen alle Personen in eine Tabelle und über ein Feld Kategorien bilden. Die Unterscheidung Jugendliche/Erwachse würde über das gespeicherte Geburtsdatum und das daraus zu errechnende aktuelle Alter abgebildet.
In Deinem Fall ist nicht zu erwarten, dass es mittelfristig Performanceprobleme gibt. Für die Einschränkung der Datenmenge bieten sich wie bereits gesagt Views an, die bspw. nur aktive, zahlende, neue, ausgeschiedene, whatever, .. Mitglieder liefern.