DbsetScope + Index [ERLEDIGT]

[Manfred]

Hi,

ich stehe mal wieder vor einem Knoten. Folgendes ist angesagt:

1) DB1
2) DB2
3) DB3
4) DB4

in Db1 wurde was gefunden und dann ein DBSETSCOPE() auf DB2 gesetzt als Anfangs- und Endwert. Jetzt baue ich eine Relation zwischen DB2 und DB3 und eine Relation zwischen DB3 und Db4. Über einen XBPbrowse() zeige ich das Ergebnis aus DB4 an. Das klappt auch prima, nur ist das Ergebnis aus DB4 sequentiell, weil es ja über die SatzId geht. Ich hätte aber gerne, wenn ich DB4 nach einem bestimmten Feld sortiert hätte. Ich habe das jetzt so ausprobiert, ohne direkt nachzudenken, dass es ja unsortiert ist. Vorher hatte ich alles über temporäre Dateien gemacht, das hat aber zur Folge, dass der Anwender teilweise Däumchen gedreht hat, bis die erste Anzeige kam. Über diesen Weg, wie oben beschrieben, wird wenigstens sofort angezeigt, aber unsortiert.

hat jemand eine Idee, wie ich irgendwie einen "temporären" Index mit ins Spiel bringen kann, der nur über das Ergebnis von DB4 gelegt wird? ODer wie, oder was?

[Martin Altmann]

Hallo Manfred,
mal wieder meine Lieblingsantwort zu solchen Dingen:
Lies die Werte in ein Array, sortiere dieses entsprechend und arbeite damit.

Viele Grüße,
Martin

[Tom]

Genügt nicht ein verknüpfter Index auf Db4?

INDEX ON Str(SatzId,10,0)+NAME TO DB4

DbSetScope(SCOPE_BOTH,Str(Db1->SatzId,10,0))

[Manfred]

Hi Martin,

direkt vorab, Dein Vorschlag in Ehren, aber das ist das gleiche wie eine temporäre Datei. Ich muß vorher die Source Datei durchlaufen und dann in ein Ziel schreiben. Das will ich mir eigentlich verkneifen. Diese Idee hatte ich auch schon gehabt, aber die Zeit ist nervig dabei.

@Tom,

sowas hatte ich mir auch schon gedacht, kann es mir aber nicht vorstellen wie es klappen soll. Werde es aber jetzt mal eben ausprobieren.

[brandelh]

Hallo Manfred,

wenn die zusätzliche Sortierung nicht schon vorher bekannt ist (also immer wieder auf das Feld vorkommt), könnte man eventuell hingehen und auf den Satz springen und mit der FOR Clausel den neuen Index einschränken ... je nach Datenmaterial könnte das klappen, aber Martins Vorschlag mit den Arrays erscheint mir in Verbindung mit Quickbrowse und aSort die schnellere und flexiblere Lösung zu sein.

[Tom]

Hallo, Martin.

mal wieder meine Lieblingsantwort zu solchen Dingen

Das mag auch bei Deinen Single-User-Anwendungen machbar sein, aber bei in Netzwerken genutzten Applikationen, die auch "live" auf Datenänderungen reagieren müssen, scheitert das. Mal von der Datenmenge abgesehen.

@Manfred: Funktioniert mit Scopes und Relationen. Einfach den gewünschten Sortierungsausdruck als zweiten Teil eines verketteten Indexes angeben.

[Manfred]

Hi Hubert,

Hallo Manfred,

wenn die zusätzliche Sortierung nicht schon vorher bekannt ist (also immer wieder auf das Feld vorkommt), könnte man eventuell hingehen und auf den Satz springen und mit der FOR Clausel den neuen Index einschränken

an sowas hatte ich irgendwie gedacht. Aber ich habe keine Ahnung wie man sowas macht, bzw. habe es bisher nicht kapiert.

... je nach Datenmaterial könnte das klappen, aber Martins Vorschlag mit den Arrays erscheint mir in Verbindung mit Quickbrowse und aSort die schnellere und flexiblere Lösung zu sein.

Wie schon erwähnt, sowas ähnliches hatte ich schon, erfordert aber ein Skippen in der DB2 und das nervt den Anwender.

[Manfred]

Hi Tom,

ich habe das gerade vorbereitet und teste es mal. Ich sage gleich Bescheid, wie das Ergebnis bei mir ist.

[Manfred]

Hi Tom,

das war glaube ich jetzt verkehrt gedacht, oder aber von meiner Seite undeutlich erklärt.

Hier nochmals:

DB1 = titel -> bez , id
DB2 = stamm -> idtitel, id
DB3 = stammDarst -> idstamm , iddarst
DB4 = darst -> id, bez

in DB1 wird nach Titel gesucht dann
stamm->(dbsetscope(scope_both,Str(titel->id,8,0)))
stamm->(Dbsetrelation(stammdarst) über stamm->id in stammdarst->idstamm
stammdarst->(dbsetrelation(darst) über stammdarst->iddarst in darst->id

jetzt wird ein Xbpbrowse() über stamm gemacht und dabei das feld darst->bez angezeigt.

Und das ist jetzt in der Reihenfolge:

stamm->stammdarst->darst also darst->bez <> sortiert

kommt das so besser rüber?

[brandelh]

Hallo Manfred,

angenommen die DB4 würde über die DB3 per Feld KundenNr angesprungen, zudem diese mehrere Datensätze enthält. Bei jeder Abfrage möchtest du die DB4 Daten sortiert nach dem Feld (RechDatum) anzeigen. Das ist die Fixe Verbindung, die man leicht (wie Tom geschrieben hat) einbauen kann:

Code: Alles auswählen

index on str(KundenNr,6)+dtos(RechDatum) ...
set scope to str(KundenNr,6)  zeigt alle an, sortiert nach RechDatum

wenn du jetzt aber mehrere Felder als Sortierfelder willst, wird es ziemlich aufwändig. Je mehr Indexdateien gleichzeitig auf sind umso langsamer wird alles, aber 3 bis 4 wären kein Problem.

Code: Alles auswählen

index on str(KundenNr,6)+dtos(RechDatum) ...
index on str(KundenNr,6)+str(PositionNr,6) ...
index on str(KundenNr,6)+BetreuerID ...

dynamisch erzeugte Indexe würden dann halt einfach

Code: Alles auswählen

dbseek(cSuchKundeNr)
if found()
   index on str(PositionNr,6) ;
            for str(KundenNr,6)=cSuchKundeNr ;
            while str(KundenNr,6)=cSuchKundeNr ;
            REST to TempIndex
...

Je nach Datenmenge kann das dauern, aber bis etwa 100 Datensätze mit vorselectiertem DBSEEK und REST sollte das schnell sein.

Wieso dein Anwender aber bei einer Arraylösung was mitbekommt versteh ich jetzt nicht. Es sei denn er will direkt im Browse editieren, dann ist das nicht ganz so einfach.

[Manfred]

Hi Hubert,

kurz `ne Erklärung dazu.

Ich skippe den Stamm durch innerhalb der gefundenen/gefilterten/gescopten Sätze. Wenn ich jetzt über 1000 Sätze gefunden habe, dann müssen die erst als Ergebnis in eine Tempdatei/array oder sonstwas geschrieben werden und dann werden sie erst gebrowsed.

Da im Multimediabereich solche Kombinationen oft vorkommen (Mach Dir mal Gedanken darüber, wieviel verschiedene Interpreten es zu "Greatest Hits" gibt), ist bei jedem 3-4 Suchvorgang sowas angesagt.

Es ist aber nicht tödlich, ich habe nur gerade durch Zufall etwas rumprobiert und dann eben diese Idee gehabt. Es ging sauschnell. Bis mir eben auffiel, warum ich diese Lösung nicht genommen habe: Sie war nicht sortiert. Und das ist ärgerlich, weil im Ergebnis des Browsefensters zwar nicht editiert wird, aber es sollte bei so großen Ergebnissen schon die Möglichkeit des Suchens über den Index möglich sein. Und das ist natürlich über die Zwischendatei machbar.

Also das mit dem bedingten Index habe ich noch nicht so ganz gefressen. Mit dem Index auf ID+Name, das bringt nichts, es ändert sich nichts, weil die Sätze in erster Linie durcheinander rüberkommen und somit auch ein erweiterter Index nichts vermag. Der Stamm ist maßgebend und der ist nicht sortiert.

Das ist das Leidwesen der Normalisierung.....

[brandelh]

Hallo Manfred,

du brauchst doch in jeder Ebene Indexdateien und die in der 4. Ebene brauchen halt zusätzlich noch den gewünschten Sortierbegriff.

Das Umkopieren in eine andere Datei ist sicher etwas zeitaufwändiger, aber wenn du mit DBSCOPE den Wertebereich eingeschränkt hast und dann mit dbeval({ aadd(aDaten, {feld1, feld2, feld3 ...})}) das Datenarray baust, danach asort auf die gewünschte Arrayspalte machst und ein Quickbrowse anzeigst, kann das nicht langsamer sein als die unsortierte Anzeige, denn die Daten werden genau einmal von Platte gelesen !

[Manfred]

Hi Hubert,

Code: Alles auswählen

(oTitel:nArea)->(DbSeek(UPPER(oTitel:bez),.T.,"bez"))
IF ! oTitel:browsedb("bez",.F.,"titel",.T.)
    oTitel:lSuchen := .F.
    LOOP
ENDIF
oTitel:readRecord(oTitel)
(oVostamm:nArea)->  (OrdSetFocus("idtitel"))
(oVostDarst:nArea)->(OrdSetFocus("idvostamm"))
(oVostamm:nArea)->  (Dbseek(Str(oTitel:id,8,0)))  // jetzt wird nach dem Stammsatz gesucht
(oVostamm:nArea)->  (DbSetScope(SCOPE_BOTH,STR(oTitel:id,8,0)))
(oVostamm:nArea)->  (DbSetRelation((oVostDarst:nArea),{|| Str((oVostamm:nArea)->id,8,0)}          ,"Str((oVostamm:nArea)->id,8,0)"))
(oVostDarst:nArea)->(DbSetRelation((oDarst:nArea)    ,{|| Str((oVostDarst:nArea)->idinterpre,8,0)},"Str((oVostDarst:nArea)->idinterpre,8,0)"))
oVostamm:browsedb2("",.T.,"interpret",.T.)
(oVostamm:nArea)->(DbClearScope())
(oVostDarst:nArea)->(OrdSetFocus("idinterpre"))
(oVostamm:nArea)->(OrdSetFocus("id"))

[/size]

bei dem oVostamm:browsedb2() wird schon direkt angezeigt im Fenster. Wenn ich die Daten erst aufbereiten muß, dann erscheint ab da nur ein BITTE WARTEN Fenster. Also kann es nicht nur ein wenig schneller sein, als mit der Tempdatei/Array

[brandelh]

Hallo Manfred,

du hast also entweder mehrere Browser auf dem Fenster oder mehrere DBFs in einem Browser bei der Anzeige ?
Das kann natürlich zu Rückkopplungseffekten kommen.
Dennoch muss das Zusammenbauen im Array von ein paar Hundert Datensätzen schneller sein, als diese von Platte zu Platte zu kopieren.

Da fällt mir ein, Steffen hat den SORT Befehl in diesem Zusammenhang gelobt, mit diesem und einem gut einschränkenden Scope könnte man schnell sortierte temporäre Dateien bauen.

Ob das aber bei dir passt kann ich nicht beurteilen.

[Rolf Ramacher]

Hallo Manfred,

ich mache dies immer folgendermaßen

meistens habe ich dies beim start des Main-Programms das Indexdateien
festgelegt werden.

Index on xxx tag "xxxx" to ">name der index-Datei>.cdx"

beim bearbeiten nachher in den Programmroutinen nach dem use
set index to ">name der index-Datei>.cdx"

name der Datenbank ordsetfocus(>tagname<)

Hierbei kannst du mehrere Indexsortierungen in einer cdx-Datei gestalten.

[Manfred]

Moin,

ich habe gerade mal wieder ein wenig in der Anleitung herumgestöbert und bin dabei auf OrdCondSet() gestoßen.

Könnte das evtl. eine Lösung sein? Hat schon jemand damit irgendwas gemacht?

Im Moment weiß ich aber mal wieder nicht, wie das eingesetzt werden würde. Es ist kein Beispiel in der Anleitung und auch nichts in den Beispielen selbst.

[Markus Walter]

mit OrdCondset() kannst Du konditionierte Indexe erstellen.

z. B.

OrdCondSet( "!empty(STATUS)", {|| !empty(STATUS)})
OrdCreate(...)

würde einen Index erstellen, der nur die Datensätze enthält, bei denen das Feld "STATUS" nicht leer ist

[Manfred]

Hi Markus,

ja, heute ist der Tag des Lernens.

Ich wußte bis vorhin nicht wie man das einsetzt, aber dann bekam ich den Tipp mir doch etwas über Index ON zu bauen und mit /p zu kompilieren. Und siehe da, der Präprozessor zeigt dann wie es umgesetzt werden muß.

Jaha, Augen auf im Straßenverkehr. Das gilt immer noch....

[AUGE_OHR]

hi,

jetzt wird ein Xbpbrowse() über stamm gemacht und dabei das feld
darst->bez angezeigt.

Ich denke es geht nicht mit "einem" XbpBrowse, du brauchst für jede
Spalte "je ein" XbpBrowse.

Die "aktivierung" der "nächsten" Ebene würde ich im StableBlock machen
um auf den User zu reagieren.

Wenn du alle Relationen durch Seek/Scope ersetzt wäre somit auch eine
"Rückwärtz" Suche (von der letzten Spalte zur ersten Spalte) möglich.

gruss by OHR
Jimmy

[brandelh]

Ich denke es geht nicht mit "einem" XbpBrowse, du brauchst für jede Spalte "je ein" XbpBrowse.

Ich denke du meinst je Tabelle oder ?

Ich habe vor einiger Zeit eine ähnlich verkettete Sache gemacht:
Listbox mit DBF (Dateiliste), nach Auswahl wird eine zweite Listbox mit den Feldern (Feldliste) geladen. Nach deren Auswahl wurden die SLE und MLE mit den Hinweistexten geladen und angezeigt, diese Ebene wäre dann ein XbpBrowse.

Wenn man alles in ein XbpBrowse bringen will, muss man zwangsläufig eine Tabelle anlegen, die zu jedem Kinddatensatz alle höheren Daten dazukopiert, also genau das Gegenteil von Normalisierung.

[Manfred]

Hi Hubert,

ich denke mal nicht das das genau das Gegenteil von Normalisierung ist. Das was eine SQL Anfrage zurückliefert wäre dann ja auch das Gegenteil dazu!? Die Daten müssen halt in einer Zwischentabelle gespeichert werden. Die Normalisierung ist ja eher auf die festen Tabellen bezogen und nicht auf temporäre.

[brandelh]

Hallo Manfred,

ich hatte das nicht negativ gemeint. Je nach Zweck ist eine solche Zwischendatei sicher sehr sinnvoll.

[Manfred]

Hi Hubert,

so habe ich es auch nicht aufgefasst. Es kam schon wie eine nachdenkliche Bemerkung von Dir rüber.

[Manfred]

Hi,

ich bringe das mal hier rein, weil es m.E. genau paßt.

Vorhin ist mir etwas sehr schwerwiegendes aufgefallen:

Vorab eine kleine Erklärung zu dem Sachverhalt
Sätze, die in meiner DB gelöscht werden, werden mit leeren Werten überschrieben, damit sie im Index am Anfang stehen und dann direkt bei einem neuen Satz zuerst überschrieben werden können. (Hinauszögern des Packen einer DB) Gleichzeitig werden sie als gelöscht kennzeichnet (Delete)

Jetzt suche ich über den Index einen Satz und mache dann einen Scope auf alle weiteren gleichen ID´s.

Code: Alles auswählen

Setscope blah blah

Do while ! db->eof()
    skip
enddo

Das ist klar, die Schleife wird solange durchlaufen, bis der Scope nicht mehr stimmt. So, jetzt kommt aber das Fatale:

Code: Alles auswählen

Setscope blah blah

Do while ! db->eof()
    satzleeren und zurückschreiben
    delete
    skip
enddo

Innerhalb der Schleife muß der bearbeitete Satz, der zum Scope paßt, nach der Bearbeitung gelöscht werden. Also wird/würde er jetzt geleert und dann deleted.

Und somit wird die Schleife beendet, weil EOF() geliefert wird.
Wie löst man so ein Problem?

[Tom]

Hallo, Manfred.

Da gibt es elegante Lösungen für, aber interimsmäßig geht auch sowas:

Code: Alles auswählen

Do while ! db->eof()
    skip
    nRecno := recno()
    skip -1
    satzleeren und zurückschreiben
    delete
    go nRecno
enddo