TTable Filtern

[f4k3]

Moin Moin liebe DP'ler,

ich hab nen Screen auf dem die Kunden mit Ihren Terminen stehen.
Quasi ein elektronisches Terminboard angezeigt auf nen dicken Flatscreen ;) *hrhr*

Nun isses aber so dass in meiner Terminverwaltung gnadenlos für jeden tag ein Termin eingetragen werden kann.

Ich muss also beim Screen meine TTable filtern. und dass mit 2 Argumenten.

Einmal das Datum des Datensatzes mit dem heutigen Datum vergleichen
und Nummero Duo ob der Kunde angezeigt werden darf (Datenschutzgründe) also Pseudo-Code Show = True;

Ich hab in der Hilfe gelesen dass TTable.Filter nur ein Argument haben darf,
und nicht mit and verknüpft werden kann ...

Ich habs nun über ne TQuery-Komponente probiert, aber leider filtert er mir nix.
Ich hab den Query mit ner datasource verbunden. Ein DBGrid ist ebenfalls mit dieser Datasource verbunden.
Meine SQl-Anweisung im Query sieht folgendermaßen aus:

SQL-Code:

SELECT * FROM TermineService.DB WHERE 'Datum' = <aktuelles Datum> AND 'Show' = True;

für das aktuelle Datum weiß ich noch nich den Code wie ich mir das holen könnte. wär auch ne frage an euch ;)

Wenn ichs so probiere:

SQL-Code:

SELECT * FROM TermineService.DB WHERE 'Show' = True;

Zeigt er mir alle Datensätze an, ob Show = False oder Show = True hinterlegt ist.

Wo ist also nun der Fehler den ich mach?

Oder liegts einfach daran dass unter anderem Paradox sehr beschränkt ist?!

Danke für eure Antworten,


Euer f4k3 ;)

[marabu]

Hallo Fake,

Zitat:

Zitat von f4k3

... Ich hab in der Hilfe gelesen dass TTable.Filter nur ein Argument haben darf,
und nicht mit and verknüpft werden kann ...

wo genau hast du das denn gelesen?

In deinem SQL-Code darfst du Feldnamen nicht einfach in Quotes einschließen, sie werden sonst als Literale angesehen.

SQL-Code:

SELECT * FROM TermineService.DB WHERE 'Datum' = <aktuelles Datum> AND 'Show' = True;

Zitat:

Zitat von f4k3

... Oder liegts einfach daran dass unter anderem Paradox sehr beschränkt ist?! ...

Bei einer Software, die viele Jahre kommerziell vermarktet wurde, würde ich den Fehler immer zuerst bei mir suchen.

Grüße vom marabu

[mkinzler]

Zitat:

f4k3 hat folgendes geschrieben:
... Oder liegts einfach daran dass unter anderem Paradox sehr beschränkt ist?! ...

Bei einer Software, die viele Jahre kommerziell vermarktet wurde, würde ich den Fehler immer zuerst bei mir suchen.

Ich würde aber heutzutage trotzdem kein Programm mit der BDE starten

[f4k3]

War ja nur ne frage weil wenn man n comment zu Paradox-Datenbanken bekommt, dann wird einem meistens empfohlen auf Firebird etc. umzusteigen weil Paradox nicht mehr mithalten kann ...

Die Aussage basiert also rein auf requests von den Usern hier im Forum.

Ähm ja also des mim Filtern hab ich mitlerweile schon ... über ne TQuery klappt des ganz gut ...
mein Prob is nur dass er mir abgelaufene Datensätze nicht mehr rauskickt ...

aber da is basteln angesagt ... danke für deine hilfe marabu ;)

[mkinzler]

Du hast Recht Paradox ist nur bei Benutzern dieses Forums aus und habe keine Ahnung und plappere nur die Meinung von anderen nach. :wall:

[f4k3]

Zitat:

Zitat von mkinzler

Du hast Recht Paradox ist nur bei Benutzern dieses Forums aus und habe keine Ahnung und plappere nur die Meinung von anderen nach. :wall:

www.deutsch.de?!

Kannst mal des vernünftig Formulieren weil aus dem gestammel kann ich mir keinen reim machen ...

Ich hab ja nicht gesagt dass du die Meinung von anderen nachplapperst ... und dass du keine Ahnung hast hab ich auch in keiner zeile erwähnt ...

also wo is dei problem?

[bluesbear]

Zitat:

Zitat von f4k3

Ich muss also beim Screen meine TTable filtern. und dass mit 2 Argumenten.

Mit TTabel.OnFilterRecord kann man sowas prima machen.

[hoika]

Hallo,

zur Query

Delphi-Quellcode:

with Query do
begin
  Close;

  SQL.Clear;
  SQL.Add('SELECT * FROM TermineService');
  SQL.Add(WHERE (Datum=:Datum) And (Show=:Show)');
  ParamByName('Datum').AsDateTime:= Date; // z.B. heute
  ParamByName('Show').AsBoolean:= True;
  Open;

  ...
end;

Interessant ist noch, welchen Datentyp Show hat.

Und wie immer ein Wort zur BDE ;)
Die BDE-Weiterentwicklung ist schon vor NT4 praktisch zum Erliegen gekommen.
in einem schöne c't - Artikel stand sehr sinnvoll "anachronistischer Sperrmechanismus".
Das Vorgehen von Paradox beim Sperren von Records bekommt bei
opportunistischen Sperren (opportunistic lock) nen Haufen Probleme,
und jedes neuere BS benutzt diese Art von Sperren.


Heiko

[bluesbear]

Ich bin leider berufsbedingt einer der Experten für antike Technik hier.
BDE, Paradox und TQuery - lieber nicht. Es funktioniert "meistens". Meiner Erfahrung nach funktioniert das OnFilter event von TTable allerdings äußerst zuverlässig.
Multiuseranwendungen damit...

Zitat:

in einem schöne c't - Artikel stand sehr sinnvoll "anachronistischer Sperrmechanismus".

Das ist ein sehr schöner Euphemismus :-D

[hoika]

Hallo,

das Wort musste ich erst mal suchen ;)

http://www.uni-essen.de/einladung/Vo...k/euphemis.htm


Heiko

[f4k3]

Zitat:

Zitat von hoika

Hallo,

zur Query

Delphi-Quellcode:

with Query do
begin
  Close;

  SQL.Clear;
  SQL.Add('SELECT * FROM TermineService');
  SQL.Add(WHERE (Datum=:Datum) And (Show=:Show)');
  ParamByName('Datum').AsDateTime:= Date; // z.B. heute
  ParamByName('Show').AsBoolean:= True;
  Open;

  ...
end;

Interessant ist noch, welchen Datentyp Show hat.

Und wie immer ein Wort zur BDE ;)
Die BDE-Weiterentwicklung ist schon vor NT4 praktisch zum Erliegen gekommen.
in einem schöne c't - Artikel stand sehr sinnvoll "anachronistischer Sperrmechanismus".
Das Vorgehen von Paradox beim Sperren von Records bekommt bei
opportunistischen Sperren (opportunistic lock) nen Haufen Probleme,
und jedes neuere BS benutzt diese Art von Sperren.


Heiko

Show hat den Datentyp Boolean ... ist also ein logisches Feld.
Des mit den ParamByName hatte ich z.B. nicht in meinem Code ... könnte daran liegen ...
Es hat zwar eigentlich funktioniert ... aber is auch vorgekommen dass manchmal ein Datensatz "vergessen" wurde ...

i'll try it ... danke für deine Hilfe ;)

[hoika]

Hallo,

ist es zufällig ein Datensatz, der erst vor kurzem eingetragen wurde,
vielleicht noch von einem anderen Rechner aus ?

-> dann willkommen bei Paradox im Netzwerk.

Nach jedem Schreiben per TTable muss ein DbiSaveChanges(Table.Handle) gemacht werden,
sonst wird das lokal noch gepuffert und "irgendwann" in die Tabelle geschrieben.


Heiko

[bluesbear]

In der BDE Verwaltung sollte außerdem LOCAL SHARE auf TRUE eingestellt sein.

[f4k3]

Zitat:

Zitat von hoika

Hallo,

ist es zufällig ein Datensatz, der erst vor kurzem eingetragen wurde,
vielleicht noch von einem anderen Rechner aus ?

-> dann willkommen bei Paradox im Netzwerk.

Nach jedem Schreiben per TTable muss ein DbiSaveChanges(Table.Handle) gemacht werden,
sonst wird das lokal noch gepuffert und "irgendwann" in die Tabelle geschrieben.


Heiko

um sicher zu gehen hab ich des mit einer leeren "Test-Datenbank" ausprobiert ...
diese hat die gleiche Struktur ... ist also identisch ...

Hab die Table mit datensätzen manuell gefüllt ... also kann eigentlich nicht daran liegen ...

Gibts vllt. irgendwo ein umfangreiches Tutorial zu Paradox?

Ich hab zwar als ich mit Delphi und Paradox-Datenbanken angefangen die Tutorials auf Delphi-Treff
zu machen ... aber die behandeln dann anscheinend auch nur die oberfläche ... liegt vllt. auch daran dass Paradox nicht mehr weiterentwickelt wird
und die meisten eine andere Datenbank nehmen ...

[f4k3]

Zitat:

Zitat von bluesbear

In der BDE Verwaltung sollte außerdem LOCAL SHARE auf TRUE eingestellt sein.

Kannst mir auch erklären warum es auf TRUE eingellst sein sollte?

[bluesbear]

Das stellt die von Hoika erwähnte Pufferung ab.

[f4k3]

Zitat:

Zitat von bluesbear

Das stellt die von Hoika erwähnte Pufferung ab.

okay ;) super danke :D

[Peinhard]

Dann will ich hier auch noch mal mein sauer Bier anbieten... und wenn es nur deswegen ist, dass DBISaveChanges() in der Komponente schon automatisch stattfindet. Insgesamt aber, da kann ich den anderen hier nur zustimmen, kann man nicht dazu raten, heute noch was mit Paradox anzufangen - es sei denn, man ist auf eine Menge lustiger Erfahrungen aus. Die man anschliessend aber auch gleich wieder in die Tonne treten kann, denn - this database format is an ex-format, it is pushing up the daisies, it rests in peace, has joined the quire invisible uswusf... und das sagt dir jemand, der seit Paradox 3.5/DOS ein recht enges Verhältnis pflegte und viele kleine und mittlere Projekte damit durchgezogen hat. Mein letzter Disput mit Borland bzgl eines Fehlers in der Indexsortierung endete schon vor Jahren nach vielem hin und her mit der lakonischen Bemerkung 'Ok, it is a bug, but we won't fix it...'.

[hoika]

Hallo,

Bei Verwendung von Windows als Server
erkennt die BDE nicht, dass der DB-Pfad ein Netzwerk-Pfad ist
und sperrt die Datensätze nicht richtig.

Das Netzwerk nennt man auch peer-to-peer.

2. Punkt
Auf dem Rechner, wo die Daten liegen,
ist das Programm auch drauf und es wird damit gearbeitet.
Dann muss die BDE auch wissen, dass auf die Daten noch von woanders
im Netz zugegriffen wird.


Jetzt fragst du dich vielleicht, wieso die BDE das nicht erkennt?
Nun ja, siehe mein voriges Posting über NT4.

Die BDE war ursprünglich designt, um unter Novell zu laufen,
das war das noch richtig stabil,
dann kam Windows und ... k.T. ;)

Es gibt ein gutes Dokument dazu.
http://wall.riscom.net/books/delphi/bde_tis/TI2989.html

Noch eine kleine Episode zu "habe es getestet, war alles OK".
Wir hatten mal nen Kunden, der ist von Novell auf Windows umgestiegen.
Es kam vermehrt zu Indexfehlern (oplocks waren noch an, kannte ich damals nicht ...),
sehr nervig für den Kunden und mich.
Ich habe versucht, das Problem nachzustellen bei uns im Büro.
Dazu habe ich 3 Rechner im Netz gahabt, auf denen permanent in die DB geschrieben wurde,
parallel natürlich in die gleiche (Problem-Tabelle).
Es kam nie ein Indexfehler.
Ich konnte das Problem also nicht lokalisieren.
Dann hat mich der Admin auf den c't-Artikel aufmerksam gemacht
(peinlich, dass ich den übersehen hatte).

Notlösung war, die oplocks am Server auszuknippsen.
Ausserdem muss lokal der Schreibcache (von Windows) deaktiviert werden,
Das führt zu sehr schönen frustrierten Nutzern
"Das Speichern dauert unter Word jetzt sooo lange, stellen Sie das bitte wieder um"

Damit war das Problem nicht gelöst, aber die Fehler waren sehr viel weniger (aber nicht weg).

Jetzt haben wir auf Firebird umgestellt, damit läuft es bei ihm seit Jahren ohne Probleme
(O-Ton: Also Ihr Programm ist so mit das einzige, was hier ohne Probleme läuft"
-> Öl für mich ;)


Heiko

[bluesbear]

Zitat:

Zitat von Peinhard

Dann will ich hier auch noch mal mein sauer Bier anbieten...

Also wenn Du der Autor von dem Sauerbier bist - das wird hier übrigens noch eingesetzt - dann sind wir uns bei compuserve schon mal begegnet. <g>
Viele Grüße vom Waldbaer.

[Peinhard]

Na, das freut mich aber. Andererseits - macht ihr denn gar keine Fortschritte...? <g,d&r>

Compuserve - das waren noch Zeiten...

Gruß zurück von Reinhard

[bluesbear]

Zitat:

Zitat von Peinhard

Na, das freut mich aber. Andererseits - macht ihr denn gar keine Fortschritte...? <g,d&r>

Mit Fortschritten ist jetzt Schluss! Das wird eine komplette Neuentwicklung. :mrgreen:
BDE ade - endlich. Alles wird gut. :-D

[Peinhard]

Zitat:

Zitat von bluesbear

BDE ade - endlich. Alles wird gut. :-D

Zeit wird's. ;) Aber trotzdem schon heftig, was man in dieser Branche immer wieder an know-how in die Tonne treten kann bzw muss.

Mit einer - mittlerweile allerdings recht winzigen - Träne im Knopfloch, Reinhard