TTable Filtern

[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.