Inoffizielles deutsches Xbase-Forum

Hi Josef

hier ist es.

Unter Garbage Collector steht etwas darüber.
http://www.alaska-software.com/products ... s_v19.shtm

Hallo, Josef, hallo, Manfred.

Das Verlangsamungsproblem gibt es genaugenommen schon immer. Ob es auftritt, hängt davon ab, wie groß die Applikation ist und wie intensiv sie der Anwender ununterbrochen nutzt (Programmstart - Programmende). Es hat nichts mit Indexen zu tun, sondern, wie Manfred schrieb, mit dem Garbage Collector, der von der Anwendung beanspruchte Speicherressourcen wieder freigeben soll, was er in allen Versionen bis 1.82 nur unzureichend und sehr ressourcenfressend tat. Diese Problematik soll mit der 1.9 behoben sein, weshalb ich auch händeringend auf das Release warte.

Hi Tom,

hm, mich würde einmal interessieren, wie Du das Problem denn handhabst? Ich meine, was sagst Du dem Anwender, dass das Teil immer langsamer wird und eigentlich nach einer Zeit X neu gestartet werden müßte?

Hallo, Manfred.

Genau so isses. Viele Anwender haben das auch selbst rausgefunden. Was soll man auch sonst tun?

Um jetzt nochmal zum Thema zurückzukommen, was ich jetzt wohl auch nicht so ganz verstanden habe, ist: Gibt es 2 verschiedene Treiber, oder Möglichkeiten einen CDX zu erstellen?

Wie schon erwähnt, habe ich ein kleines Programm geschrieben, in dem ich einen CDX Index aufgebaut habe. Dann habe ich mit dem gleichen Schlüssel über DBEDITOR einen CDX aufgebaut und die Indexdatei wurde kleiner.

Hallo Manfred,
ich habe vor ca. 2 Jahren von NTX auf CDX umgestellt, da ich öfters Probleme mit korupten Indexen hatte und ich das extended locking bei CDX ausnutzen wollte. Ich bin mit der Umstellung zufrieden, obwohl ab und zu (allerdings jetzt sehr selten) noch korupte Indexe vorkommen.
Ein Problem hatte ich bei der Umstellung jedoch nicht bedacht, bei NTX hatte ich einfach nur die Index-Dateien neu erzeugt und das so beibehalten, bis mir auffiel, das die CDX Dateien immer größer wurden.
Wichtig ist bei CDX die Indexdatei immer erst zu löschen und dann neu zu erzeugen, da sonst die neuen Tags an die Datei angehängt werden.
Ansonsten habe ich den Ratschlag aus den Newsgroups befolgt, und nicht mehr als 5 Tags pro Indexdatei erzeugt. Meine Datenbank mit den meisten Sortierschlüsseln hat so 3 Indexdateien mit je 5 Tags.

Gruß Wolfgang

Hi Wolfgang,

endlich mal eine positive Nachricht

Einen Reindex, oder so habe ich noch nie gemacht. Da war ich glücklicherweise so schlau sofort den Rat zu befolgen, der schon immer im Handbuch stand und steht.

Ich möchte auch hauptsächlich umsteigen, weil die Indexe kleiner und eben nur noch 1x vorhanden sind.

Das mit dem Extended Locking muß ich mir auch noch genau durchlesen. (Der Tag müßte mehr als 24 Stunden haben)

Kommt aber auch erst in Betracht, wenn wirklich kein Mischbetrieb mehr vorliegt und nur noch Xbase läuft..

Hallo Manfred,

Manfred hat geschrieben:Hi Thomas

Code: Alles auswählen

dbCreateIndex("..\dbanken\vo\fstherst", "fstamm->v_bestnr + STR(fstamm->herst_nr,4,0)",{|| zeigwo(fstamm->v_bestnr + STR(fstamm->herst_nr,4,0))},NIL)

FUNCTION zeigwo(nParanr)

         @ 17,72 SAY RECNO() PICTURE "@E 999,999"
         RETURN(nParanr)

So mache ich das. Ich habe aber die zeigwo() rausgenommen und es geht doch um ein vielfaches schneller danach.
Hm, dann muß ich mir einmal Gedanken zu dem Statusbar machen.

Einige Vorschläge meinerseits:
Du möchtest den Fortschritt ja anzeigen lassen - also sorge doch dafür, dass dies nur noch bei jedem 10. (oder 30. oder 5.) Datensatz passiert! Da es natürlich doof aussieht, wenn die Datensatznummern immer nur in 10'er-Schritten hochgezählt werden, solltest Du eine Funktion bauen, die statt der Ausgabe der Datensatznummer einen Balken zeichnet.
Da der Balken natürlich prozentual gefüllt werden soll, müsstest Du vorher ermitteln, wie viele Datensätze Deine Datei hat und dann einen entsprechenden prozentualen Faktor bestimmen. Wenn Du also in 10%-Schritten vorwärts gehen willst, müsstest Du die Anzahl der Datensätze durch 10 teilen. Bei 5% durch 20, usw.
Beispiel: So würde Deine Datensatznummer in gleichmäßiger Geschwindigkeit (gleichmäßige Sprünge) hochgezählt.
Ein Balken wäre aber optisch sicherlich schöner. Den kannst Du ja in Deiner Funktion zeigwo() erzeugen.

Viele Grüße,
Martin

Hi Martin,

danke erstmal. Vorab noch eine Frage:

Hast Du, oder ein anderer Leser hier, eine Ahnung, was denn da so bremst? Die Anzeige, oder der Zugriff auf den Record des Satzes? Ich hatte nämlich Anfangs nur eine Variable in zeigwo() installiert, die hochgezählt wurde. Das ging aber, so weit ich mich noch erinnern kann, total in die Hose, weil der Index irgendwie platt war danach. Das habe ich auch nicht so richtig verstanden, warum das so war. Der Codeblock wird ja abgespeichert im Index.

Bei der Anzeige reicht es auch, wenn in 100er Schritten angezeigt wird. Es geht nur darum, dass der User etwas sieht, sonst wird der nervös und schaltet evtl. ab, oder startet neu. (Alles schon da gewesen). Die Sache mit dem Balken, ist mir aber noch am liebsten, das sollte auch im Textmodus machbar sein.

Oops, fällt mir gerade noch ein:

Diese Funktion zeigwo() hat einen heftigen Nachteil, sie erscheint irgendwie auch am Bildschirm wenn kein Index aufgebaut wird, sondern noch bei anderen Gelegenheiten. Deshalb muß sie sowieso raus.

Hallo Manfred,
soweit ich weiß, eindeutig die Bildschirmausgabe!
Das Hochzählen muss klappen! Entscheidend ist, dass Deine Funktion in jedem Fall den Indexausdruck zurück geben muss (wie es ja im Moment auch ist)!

Viele Grüße,
Martin

Hi Martin,

wie sagt man so schön? Vor lauter Wald keine Bäume sehen. Der Tipp war gut. Das ich da nicht direkt selbst drauf gekommen bin. Das Tempo und die Anzeige stehen in einem richtig guten Verhältnis zueinander. Was voher etliche Minuten dauerte, ist jetzt bei 2 Durchläufen mit je 610.000 Sätzen in knappe 40 Sekunden durch. Komisch, ich hätte unter Clipper schwören können, dass es nicht so ein drastischer Unterschied war. Sicherlich war die Hardware damals nicht so schnell..... Naja, egal, Hauptsache es klappt.

Jetzt werde ich einmal abwarten, ob der Index auch i.O. bleibt.

Hallo Manfred,

ich betreibe ein Warenwirtschaftssystem mit Xbase++ und ntx seit ca 20 Jahren bei mehreren Kunden. Habe grad mal gescannt, mehr als 465 Indexdateien, über 100 dbf´s - mehrere Nutzer gleichzeitig im Netz - funktioniert einwandfrei. Ich führe die Indexdateien dauerhaft.

Nach jedem unkontrollierten Absturz zwinge ich zu einem Reorg - alle Indexdateien neu erstellen. Das kommt jedoch fast nie vor.

Diese Riesensystem habe ich auch von Clipper auf Xbase++ umgestellt. Zuerst ohne Änderungen, dann Drucken über Win-Drucker usw..

Ich habe schon mehrere Clipper-Monster portiert (auch eines, das schon 4 Softwarefirmen mit mehreren Mitarbeitern geschrieben haben - grauenhaft ).

Das geht schon - hier hat´s ja lustige Icons


Gruss, Armin

Hallo Armin.

Na endlich mal einer der gute Erfahrung mit DBFNTX gesammelt hat.
Ich kann Deine Ausführungen nur bestätigen !
Auch in unseren Anwendung benutzen wir ein Vielzahl von Indexdateien und konnten bisher nur
ganz wenige Problem mit korrupten Indexen feststellen.
Setzt man die mit Xbase++ erzeugten oder veränderten Datensätze im Verhältnis zu den
festgestellten Index Problemen, so komme ich auf einen Verhältnis von 1 : 10.000.000.
In den vergangenen 14 Jahren habe wir ca. 85 Mio. Datensätze erzeugt und insgesamt 9 mal Probleme mit korrupte Indexe gehabt.
Acht dieser Vorgänge haben die User selber produziert und einen Vorgang aus dem letzten Jahr konnte wir nicht eindeutig klären.
Also ich denke, das die Benutzung von DBFNTX sehr gut funktioniert.

Gruß

Thomas

Hallo Armin und Thomas,
gut zu wissen! Ich werde nämlich wahrscheinlich nicht drumherum kommen, mit einem dauerhaften Index bei unserem Webserver zu arbeiten! Wir wollen da nämlich noch einen Mehrwert schaffen, indem wir alle jemals online gemeldeten Hunde in einem extra Hauptarchiv aufheben. Sobald dann jemand Zuchtbuchnummer, Geschlecht und Wurfdatum des zu meldenden Hundes eingegeben hat, wird dieser automatisch gesucht und (sofern gefunden) die anderen Felder sofort in der Webseite mit den im Archiv hinterlegten Werten vorbelegt.
Da dieses Hauptarchiv natürlich immer geöffnet ist und immer aktualisiert werden muss, kommen wir um einen dauerhaften Index ja leider nicht drum herum!
Viele Grüße,
Martin

Ich kann die Erfahrungen auch nur unterstreichen. Wenn Index-Korruptionen auftreten, lassen sie sich in den allermeisten Fällen auf drei Ursachen zurückführen:

a) Rechnerausfall (oder -abschaltung)
b) Programmierfehler 1: Indexausdrücke wie Trim(Name)+Trim(Vorname) (selten)
c) Programmierfehler 2: Ein Index (von mehreren) war nicht geöffnet, als ein ihn betreffendes Feld aktualisiert wurde (Clipper-Erbe; damals haben wir versucht, die Anzahl der geöffneten Dateien möglichst gering zu halten, und von diesen Ecken gibt's noch zwei oder drei)

Wir haben ziemlich viele Kunden, bekommen aber höchstens einmal pro Woche eine Fehlermeldung, die sich auf Indexkorruptionen zurückführen läßt (leider "reduziert" Xbase 1.82 alle Indexfehler auf "Betriebssystemfehler 1 - unzulässige Funktion"), und das bei hunderten von permanenten Indexen, alles DBFNTX.

Hallo Martin.

Nur ein kleiner Tipp von mir.
Lass doch die Tierbesitzer die Hunden scannen und schon sind Sie auf richtigen Datensatz.
(Sh. Link : http://www.virbac.de/tierhalter/tier_id ... eraete.asp )

Die Eingabe von Zuchtbuchnummer, Geschlecht und Wurfdatum entfällt dann.

Gruß

Thomas

Hallo Thomas,
an sich eine gute Idee, nur sind halt leider nicht alle Hunde gechipt.
Viele Grüße,
Martin

Ausschlaggebend für mein Thema war halt meine Erfahrung unter CLipper damit, dass immer wieder und zwar recht häufig, ein defekter Index vorlag.

Hm, oder sagen wir einmal so: Clippers Errorsys hat es zumindest so behauptet, wenn ich EG_CORRUPTION abgefragt habe. Und das eine DB immer nur solange defekt war, bis der Index neu aufgebaut wurde, würde doch recht nachdenklich stimmen.

Allerdings bin ich dabei diese ganze alte Struktur derzeit in Xbase zu ändern, weil ich, nach all den Aussagen hier, der Meinung bin, es lag wohl eher ein Designfehler vor.

Trotzdem reizt mich die Sache mit dem CDX sehr und ich werde es mir nochmals überlegen, in welche Richtung ich gehen werde

Hallo Tom,

Tom hat geschrieben:

Vielen Dank für den Smily! Kann ich gut gebrauchen

Viele Grüße,
Martin

Hallo Tom,

Tom hat geschrieben:b) Programmierfehler 1: Indexausdrücke wie Trim(Name)+Trim(Vorname) (selten)

Ganz blöd gefragt: Was ist denn daran falsch?

Jan

Beim Trim() in einem Index, wird der Schlüssel unterschiedlich lang. Regulär müßte eine Auffüllung mit entsprechenden Leerzeichen dahinter gemacht werden.

So hatte man mir das damals von CA erklärt.

Hallo Jan,
ein Indexausdruck muss immer (bei jedem Datensatz) die gleiche Länge haben!
Trim schneidet Leerstellen ab, dadurch ist (sehr wahrscheinlich) die Länge bei jedem Datensatz unterschiedlich!

Viele Grüße,
Martin

Manfred war schneller

Hallo, Jan.

Was ist denn daran falsch?

Ein Indexausdruck muß immer einen Wert von konstanter Länge liefern.

Xbase-Docs, Thema "INDEX - Erstellt eine Indexdatei", Abschnitt "Hinweise".

Indexdateien sind sequentiell aufgebaut und haben diskreten Platz für jeden Indexwert reserviert. Trim(Name)+Trim(Vorname) jedoch erzeugt einen Wert, dessen Länge zwischen 0 (Null) und der maximalen Länge von Name + Vorname liegen kann. Dies führt zu Korruptionen.

Tom war am langsamsten.