Datensatzanzahl bei Paradox- und dBase- Tabellen?

[Volker Lauckner]

Hallo,
ich habe ein Problem:

Ich möchte die Anzahl der Datensätze einer dBase- oder Paradoxtabelle ermitteln. Da die Tabellen sehr groß sind, ist z.B. Table1.RecordCount keine Lösung.
Wie kann man den Header der Tabelle auslesen um an die Infos zu kommen?

Für einen Hinwes wäre ich dankbar.

[Michael Habbe]

Hallo Volker,
.
ich weiss nicht, ob es eine API für diese Funktion gibt.
Aber in der Datei sind scheinbar die Byte-Nummern 6-9 für die Speicherung der Anzahl der Datensätze zuständig.
Vielleicht kannst Du damit was anfangen.
.
mfg
Michae

[Jochen Reichenberg]

Was spricht dagegen, einen SELECT COUNT per SQL abzusetzen

[Bernhard Geyer]

SELECT COUNT ... wird sehr lange dauern bei solchen "Dummen" DB's.

"Table1.RecourdCount" sollte doch sehr schnell arbeiten wenn Table1 nicht mit einem Filter belegt ist. (Ich denke doch das Table1 vom Typ TTable ist)

[Michael Habbe]

Das kommt aber drauf an, ob RecordCount in den Header schaut oder die einzelnen DS zählt. Und wie Volker schreibt, scheint es wohl so zu sein

[Oswald Mair]

Vielleicht nur eine Schnapsidee
*
Wenn die Table1 geöffent wird und RecordCount nicht im Header steht, dann hat dieser ja den Wert=0
*
Mit Table1.last wird der letzte Datensatz angesprungen
Sollte eigentlich bei DB ziemlich schnell sein
*
Nun müsste doch Table1.recordCount den richtigen Wert haben
*
Oswal

[Heiko Luettge]

Hallo Volker,

also bei mir ist RecordCount sehr schnell gewesen (Paradox).<br>
bei DBase habe ich keine Ahnung.
<p>
Heik

[Volker Lauckner]

Danke für die schnellen Antworten.

Ich habe das Beispiel von Oswald getestet:

// DSAnzahl = 845976 aktuell (40 String- Felder)

Table4.Open;
Table4.Last;
DSAnzahl := Table4.RecordCount;
Table4.Close;

Das dauert genau so lange (ca. 55s)
(AMD 64-3000 ; 1536 MB RAM; 2 schnelle Platten usw.)

Das heißt, die Funktion RecordCount durchsucht in jedem Fall die Tabelle. Ich vergleiche den ermittelten Wert mit einem Registry- Eintrag, der bei Neuinstallation oder Update eingetragen wird um zu entscheiden, ob die Daten aktuell sind. Da müßte der Nutzer dann jedesmal bein Programmstart ca 1 Min. warten

Eine Volltextsuche per generierter SQL- Anweisung über mehrere Felder dauert übrigens genau so lange (45s-65s).

Ich hatte irgendwo gehört, daß die Anzahl der Datensätze bereits irgendwo im Header steht, ich weiß nur nicht, wie ich mit Delphi da rankomme.

Leider muß ich diese Flat Table ohne Index als Datenquelle benutzen, die in Zukunft mehrere Millionen DS haben soll.

Wer weiß da Rat? Ich wäre wirklich dankbar.

Volke

[Michael Habbe]

Hallo Volker,
.
zum Einen kannst Du natürlich mit Delphi auf die Tabelle direkt zugreifen, d. h. mit "File of Byte" und AssignFile, Reset, ..., um dann die 4 Bytes zu lesen und auszuwerten.
.
Zum anderen könntest Du bei Programmstart einen Thread starten, der die gewünschte Operation im Hintergrund ausführt und zum Beispiel in eine (Ini-)Datei schreibt mit Datum und Zeit. So könnten andere Clients auch gleichzeitig die Aktualität der Tabelle sehen.

<blockquote>
// DSAnzahl = 845976 aktuell (40 String- Felder)
die in Zukunft mehrere Millionen DS haben soll
</blockquote>
Du solltest für die Zukunft Abstand von der BDE nehmen, ich weiss, dass die BDE nur begrenzt einsetzbar ist. Da treten Probleme auf, an die Du heute nicht mal im Traum dran denkst.
Zudem wird die BDE nicht mehr weiterentwickelt.
.
Michae

[Heiko Luettge]

Hallo Volker,

wie schnell ist denn<P>

Table4.Open;
DSAnzahl := Table4.RecordCount;
Table4.Close;

??

Zu deiner Update-Prüfung:
Lasse von jedem Client in eine 2. Tabelle Datum und Uhrzeit des letzten Schreibzugriffs (Update/Delete) schrieben.

RecordCount zu prüfen, halte ich für keine gute Idee, ein Datensatz gelöscht, einer neu angelegt = RecordCount unverändert.
<p>
Heik

[Bernhard Geyer]

Ist das System kein Altsystem sondern eine halbwegs neue Entwicklung so ist die BDE so ziemlich das schlechteste was man machen kann.

Es gibt genügend Alternativen von Desktopdatebank (ADS Local Server, Absolut Database) über Embedded-Version von "richtigen" DBMS (MySQL, Firebird, ...) bis zu richtigen Systemen. Und wenn du gleich eine DB-Unabhänige Schicht einbaust und den direketn DB-Zugriff auf wenige Units beschrängst (pro DB-System eine Datei) so kannst Du bei bedarf die nächst größere DB verwenden.

Verrate uns doch mal wieso es eine "BDE-Datenbank" sein muss

[Volker Lauckner]

Hallo Bernhard,

ich hätte auch lieber MySQL genommen. das ist aber zur Zeit nicht möglich. Da muß ich mich erst einarbeiten und noch Überzeugungsarbeit leisten.
Ich mache das leider nur im Rahmen einer sog. MAE- Maßnahme (1 € Job), da habe ich momentan wenig Einfluß drauf.
Ich selbst würde erst die Tabelle (90% leere Felder) in die 2. NF überführen und dann mit einem SQL DBMS arbeiten. Das ist jedoch jetzt noch nicht möglich.

Hallo Heiko,

die Quelltabelle wird max. einmal monatlich aktualisiert, da kommen immer nur Daten hinzu, was drin steht, bleibt auch drin. Das Beispiel hatte ich, es dauert genau so lange.

Bei einer Neuinstalllation steht in der Registry der Wert 0, sonst der letzte aktualisierte Wert, den ich dann nur auslese und mit der DS- Anzahl der aktuellen Quelltabelle vergleiche. Diese "Monstertabelle" wird dann von meinem Programm in handliche "Stücke" geteilt.

Hallo Michael,

das mit dem Filehandling werde ich gleich mal ausprobieren, danke. Ich muß nur noch den Aufbau des DBF- Headers rauskriegen.

Danke an alle Experten

Volke

[Jochen Reichenberg]

Kannst Du testweise einen Primärindex erzeugen (vorzugsweise nicht auf einem String-Feld, sondern z.B. ein AutoInc-Feld) und die Performance nochmal testen

[Volker Lauckner]

Viele Dank für Eure Hinweise!

Ich habe das Problen so gelöst:

Ich ermittle erst die Dateigröße in einer Funktion:
...
Result := DB.Size;
...

DBGroesse := FSize(Datei);

danach lese ich die Datensatzlänge aus:

Table1.Open;
DSLaenge := Table1.RecordSize;
Table1.Close;

und Teile die Dateigröße durch die Datensatzlänge:

DSErg := DBGroesse Div DSLaenge;

Das Ergebnis stimmt immer, auch, wenn sich die Feldanzahl verändert. Und das Wichtigste: es kommt sofort

[Michael Habbe]

Hallo Volker.
<blockquote>
Das Ergebnis stimmt immer, auch, wenn sich die Feldanzahl verändert. Und das Wichtigste: es kommt sofort!
</blockquote>
Solange nur DS hinzugefügt werden, mag das stimmen, aber sobald DS auch gelöscht werden, kannst Du Dich nicht mehr darauf verlassen. Die gelöschten DS werden nämlich als frei markiert, der Speicher bleibt aber reserviert.
.
mfg
Michae