Bei Relationen sortieren

Beitrag von **Manfred** » Fr, 12. Mai 2006 16:12

Hi,

vorab, eine Grundvoraussetzung, die gegeben sein sollte:

Die Relationen klappen einwandfrei unter Xbase++.

Nachdem ich die Normalform angewandt habe, stellt sich mir nun ein Problem, für das ich irgendwie keine vernünftige, bzw. aufwandsarme Lösung finde.

Die Relationen untereinander werden ja in der Regel über numerische Felder verknüpft. z.B. Recno(), oder selbstvergebene ID-Nummern.

Jetzt bewege ich mich frisch durch die DB und finde meinen Satz, der über eine Relation mit einer anderen DB verbunden ist. Beide Schlüssel sind numerisch, aber in der anderen DB steht nun die Bezeichnung, ich ich anzeigen will. Aber auch hier wurde nicht nur 1 Datensatz gefunden, sondern mehrere. Irgendwie verbiege ich mich jetzt diese DB nach Bezeichnung sortiert auszugeben. Ich laufe hier schon die ganze Zeit im Kreis und drohe mich total zu verhaspeln.

Code: Alles auswählen

DB1         DB2           DB3
IDDB2------>ID
            IDDB3-------->ID
                          BEZ

Ich hoffe ich konnte mich ein wenig verständlich ausdrücken.

SQL DB haben ja den Vorteil das man SELECT ALL FOR DB2->ID = DB1->IDDB2 .AND. DB3->ID = DB2->IDDB3 SORT ON DB3->BEZ

ist jetzt mal so aus der Hüfte geschossen, ich habe den genauen Wortlaut nicht im Kopf. Wie machen die dass denn? Schreiben die das Ergebnis in eine Zwischendatei mit allen Feldern und sortieren dann? Wie kann man sowas unter Xbase++ ohne SQl ähnlich, oder genauso machen.

Wie gesagt, ich laufe im Kreis und komme nicht weiter.

Beitrag von **Martin Altmann** » Fr, 12. Mai 2006 16:20

Hallo Manfred,
ich selber arbeite nicht mit Relationen (schon, aber händisch - nicht mit dem entsprechenden Befehl).
Aber wenn Du sortieren willst nach einem Feld aus der DB3 - wieso baust Du denn nicht Deine Relation dann ausgehend von der DB3 auf? Also:
Index auf das Feld aus der DB3 und dann mit den anderen beiden DBs verknüpfen...

Viele Grüße,
Martin

Beitrag von **Manfred** » Fr, 12. Mai 2006 17:10

Hi Martin,

ich selber arbeite nicht mit Relationen (schon, aber händisch - nicht mit dem entsprechenden Befehl).

also Du simulierst die Relationen mit DBSEEK() oder so?
Da stellt sich mir die Frage, vom Programmieraufwand mal abgesehen, gibt es da einen Tempounterschied zwischen Relationen und selbst suchen? Hat jemand damit schon mal Erfahrungen gesammelt?

Aber wenn Du sortieren willst nach einem Feld aus der DB3 - wieso baust Du denn nicht Deine Relation dann ausgehend von der DB3 auf? Also:
Index auf das Feld aus der DB3 und dann mit den anderen beiden DBs verknüpfen...

Das geht nicht in jedem Falle rückwärts, weil ich eigentlich nach etwas ganz anderem suche und dann als letztes diese DB anspreche.

Ich suche einen EAN13, der verbindet mich dann mit dem Stamm der CD und von dort gibt es eine DB, die die Verbindung zu einem Titel, bzw. zu einem Interpreten herstellt.

1) 1 x EAN
2) 1 x Stammdaten dazu
3) 1 x Zwischendatei, die n x Interpret mit 1 x Stammsatz verbindet oder 1 x Interpret mit n x Stammsatz (je nachdem von wo man kommt)

Das gleiche geht über den Titel.

Wenn ich jetzt einen Interpreten suche, dann suche ich den in der Interpreten DB, in der nur der Interpret und die ID zur Verknüpfungsdatei (Interpret zum Stammsatz steht, weil es ja mehrere Interpreten gibt, die verschiedene Titel herausgebracht haben)

Usw. Ich weiß es ist vielleicht ein wenig schwer zu verstehen, aber es gibt alles nur 1x und wird dann entsprechend zugeordnet.

1x Stammsatz (getrennte DB)
1x Titel (getrennte DB)
1x Interpret (getrennte DB)
1x Genre (getrennte DB)
1x System (getrennte DB)
1x EAN (getrennte DB)

Und das wird dann unterschiedlich verknüpft, über DB in denen steht, welcher Interpret zu welchem Stamm gehört
welcher Titel zu welchem Stamm gehört usw

Vielleicht noch mal ganz kurz das hier:

Ich suche einen Interpreten, den finde ich. Der gefundene Satz sagt mir jetzt wieviele CDs (Stammsätze) der herausgebracht hat. Jetzt ist jeder Stammsatz der CD mit einer anderen DB verbunden, die zu jeden Stammsatz weiß, wie der Titel der CD heißt. Da aber in der Zwischendatei vom Stammsatz zum Titel der Reihe nach die einzelnen Verknüpfungen zum Titel gespeichert sind, so wie sie eingegeben wurden, sind die Titel natürlich nicht nach Name sortiert, sondern wild durcheinander. Da aber zu jedem Stammsatz nur ein Titel vorhanden ist, kann man auch nicht nach Stammsatzid+titel sortieren. Wobei das auch nur die alphabetische Reihenfolge innerhalb einer CD gewährleisten würde und nicht die alphabetische Reihenfolge aller Titel des Interpreten.

(so, jetzt ist die Verwirrung komplett

)

Beitrag von **Martin Altmann** » Fr, 12. Mai 2006 17:16

Hallo Manfred,
ah OK! Also keine 1:1, sonder 1:n bzw. m:n Beziehungen.
Nun, dann würde ich die Daten suchen, in ein Array packen und das dann sortieren - einfach und flott.
Zu Deiner einleitenden Frage: Ja, ich mache das über Index und seek, da ich nur zwei Dateien habe, die ich so miteinander verknüpfe. Reicht mir und geht so wunderbar. Da ich unter Clipper Sommer 87 damals immer mal wieder Probleme mit Relationen hatte, bin ich darauf geschwenkt und nie wieder zurück.

Viele Grüße,
Martin

Beitrag von **Manfred** » Fr, 12. Mai 2006 17:23

Also die Felder in eine Array schreiben und dann statt aus der DB mit den entsprechenden Arrayfeldinhalten die Relationen simulieren und in den anderen DB suchen?

Wie kriegt man eigentlich ein Array in einem XbpBrowse() angezeigt, besonders, wenn für das Browsen in einer DB die Sache schon fertig ist. Das habe ich bisher auch noch nicht verstanden. (Hatte ich damals bei TBROWSE() schon nicht

)

Vor allen Dingen ich muß ja eigentlich aus jeder DB die Felder anzeigen.
Also aus der einen den EAn aus der anderen die Satzdaten, aus der nächsten das Genre aus der nächsten den Titel aus der nächsten die Bestandsdaten. Sollen dann alle Ergebnisse in ein, bzw. verschiedene Arrays geschrieben und verknüpft werden? Puh, das stelle ich mir recht kompliziert vor.

Beitrag von **brandelh** » Fr, 12. Mai 2006 17:27

Hallo Manfred,

bis dein Programm (wie im Beispiel geschildert ) sich entschlossen hat, welche Relation die richtige ist, hat Martin auch seine Daten gefunden.

Der Relationen Befehl kann auch nicht schneller suchen als wenn man selbst DBSEEK aufruft. Im Gegenteil, da er mehr Möglichkeiten abdecken muss um alles sicher zu stellen, wird er eher langsamer sein.
Aber der Unterschied ist so winzig, dass man das gar nicht messen könnte.

Früher habe ich z.B. oft sowas gemacht:

dbseek()
dbeval( bTun, bFor,bwhile, für REST:=.t.) // die Parameter stimmen bestimmt nicht ...

heute mache ich es einfacher (einfacher IST besser):

dbsetScope(je nach dem was man braucht und im Index findet)
dbsetFilter(wenn ich mehr filtern muss als der Index kann)
dbeval(bTun)
alles aufheben.

Und wenn dann das Ergebnis nicht für meine Aufgabe passt, dann lade ich in Arrays und mache ein aSort().

Beitrag von **Martin Altmann** » Fr, 12. Mai 2006 17:32

Hallo Manfred,
ich dachte, es geht Dir nur um die Ausgabe. So wird das natürlich ein wenig unübersichtlicher...
Aber Du kannst ja natürlich auch mehrere parallele "Browses" aufbauen - jedes enthält nur ein Typ.
Links stehen in einer Liste alle CDs des Interpreten untereinander (alphabetisch sortiert).
Rechts daneben stehen alle Titel der links ausgewählten CD untereinander (alphabetisch sortiert).
Oben drüber ist ein Eingabefeld für die EAN-Nummer.
Vielleicht so in etwa?
Oder halt doch ein großes Browse, das soviele Zeilen hat, wie der Interpret Titel. Aber dann sind natürlich viele Daten doppelt drin (Interpret, CD-Name)

Viele Grüße,
Martin

Beitrag von **Manfred** » Fr, 12. Mai 2006 17:35

Hallo Hubert,

das mit dem DBSETSCOPE() habe ich schon mal versucht, bin aber irgendwie immer vor die Wand gelaufen.
Vielleicht kannst Du es mir anhand einers Beispiels kurz mal von Anwenderseite aus erklären?

Also bei mir sieht es so aus:

Code: Alles auswählen

               TitelVostF4->(OrdSetFocus("idvostamm"))
               titelvostF4->(DbSetRelation("titelF4",{|| STR(titelvostF4->idtitel,8,0)},"STR(titelvostF4->idtitel,8,0)"))
               vof4->(OrdSetFocus("idvostamm"))
               darstf4->(OrdSetFocus("bez"))
               darstf4->(DbSetRelation("darstvostf4", {|| STR(darstf4->id,8,0)},"STR(darstf4->id,8,0)"))
               vostf4->(DbSetRelation("vof4"        , {|| STR(vostf4->id,8,0)} ,"STR(vostf4->id,8,0)"))
               vostf4->(DbSetRelation("titelvostf4" ,{|| STR(vostf4->id,8,0)}  ,"STR(vostf4->id,8,0)"))
               darstf4->(DBSEEK(UPPER(M->oDarstF4:bez),.T.,"bez"))
               IF M->oDarstF4:browseDB(M->oDarstF4,"bez",.T.,"darstf4")
// hier käme jetzt ein browsen der Titel des Interpreten.                  
               ENDIF
               darstf4->(OrdSetFocus("id"))
               darstf4->(DbClearRelation())
               vostf4->(DbClearRelation())
               titelvostf4->(DbClearRelation())
               vof4->(OrdSetFocus("id"))

kann man das so verstehen?

Beitrag von **brandelh** » Fr, 12. Mai 2006 17:35

oops, jetzt hatte ich die letzten Antworten noch nicht gelesen und schon geschrieben ...

Manfred, ich such dir mal ein Beispiel aus, und sende es dir. Arrays sind übrigens auch deshalb ideal, da man diese beim Aufbau wie gewünscht zusammenbasteln kann und danach nicht mehr auf die Festplatte zugreifen. Das ist ein schneller Browser und auch ein paar Tausend kein Problem. Du nimmst natürlich EIN Array und das wird so gemacht, wie du später die Ausgabe haben willst. Umsortieren KEIN Problem ...

Beitrag von **Manfred** » Fr, 12. Mai 2006 17:37

Martin Altmann hat geschrieben:Hallo Manfred,
ich dachte, es geht Dir nur um die Ausgabe. So wird das natürlich ein wenig unübersichtlicher...
Aber Du kannst ja natürlich auch mehrere parallele "Browses" aufbauen - jedes enthält nur ein Typ.
Links stehen in einer Liste alle CDs des Interpreten untereinander (alphabetisch sortiert).
Rechts daneben stehen alle Titel der links ausgewählten CD untereinander (alphabetisch sortiert).
Oben drüber ist ein Eingabefeld für die EAN-Nummer.
Vielleicht so in etwa?
Oder halt doch ein großes Browse, das soviele Zeilen hat, wie der Interpret Titel. Aber dann sind natürlich viele Daten doppelt drin (Interpret, CD-Name)

GENAUSO, PRIMA,

aber wie macht man sowas? Das wäre natürlich total heiß, in dem einen Browser scrollen und der andere führt mit. Aber absoklut keine Ahnung wie das klappt. Ich habe auch schon mal in den Beispielen nachgesehen, aber keinen Schimmer davon.

Und dann natürlich hin und herspringen und im erlaubten Fenster mit RETURN, oder so übernehmen zur Weiterverabeitung

Beitrag von **Martin Altmann** » Fr, 12. Mai 2006 17:49

Hallo Manfred,
Du suchst Dir anhand der EAN erstmal den Interpreten (wie ja bisher auch).
Dann suchst Du Dir über den Interpreten alle CD-Namen, und merkst Dir die Namen der CDs und die IDs in einem Array - Spalte 1 die Namen, Spalte 2 die IDs. Dann sortierst Du Dir das Array alphabetisch nach der ersten Spalte und schreibst die Spalte 1 in eine XbpListBox (den Eintrag in der zweiten Spalte hinterlegst Du jeweils als Rückgabewert).
Nun kannst Du entweder vorab alle Titel aller CDs des Interpreten suchen und in ein Array schreiben (1. Spalte Titel, 2. Spalte ID der jeweiligen CD) und das dann nach der 1. Spalte alphabetisch sortieren (Fall 1) oder Du suchst Dir die immer dann zusammen, wenn ein Eintrag bei den CD-Namen markiert wird (Fall 2, der aber wahrscheinlich langsamer ist, wenn man häufiger in den CDs hin- und herklickt).
Wann immer in der ersten Listbox ein Eintrag markiert wird, wird die zweite Listbox geleert, und dann mit den Einträgen des zweiten Arrays gefüllt (1. Spalte), die in der 2. Spalte die ID der ausgewählten CD haben.

Viele Grüße,
Martin

Beitrag von **Tom** » Fr, 12. Mai 2006 17:58

Hört sich alles ziemlich chaotisch an. Vielleicht ging's an mir vorbei, aber was spricht erstens gegen kombinierte Indexausdrücke wie Str(ID,9,0)+Upper(Title) und zweitens gegen die Nutzung des Scoping-Systems? Das ist robust, extrem fix - und es schränkt die Sicht auf eine Tabelle exakt auf den Bereich ein, den man als Ausdruck angibt. Umschaufelei nach Arrays ist immer dann second best, wenn die Applikation im Mehrbenutzerbetrieb läuft oder wenn Daten zurückgeschrieben werden sollen.

Beitrag von **brandelh** » Fr, 12. Mai 2006 17:59

Hallo Manfred,

die Reaktion (das Markieren oder Auswählen je nachdem wie du das willst ) kannst du mit einem Callback-Codeblock steuern, siehe hierzu

:itemMarked oder
:itemSelected

der Klassen Browse, Quickbrowse (oft sinnvoller wegen Geschwindigkeit), Listbox ...

Beitrag von **Tom** » Fr, 12. Mai 2006 18:03

Kurze Erläuterung:

Scoping ist ganz simpel.

Code: Alles auswählen

DbSetScope(SCOPE_BOTH,Str(nId,9,0))

setzt einen Scope auf eine Tabelle, wobei nur noch die Datensätze angezeigt werden, die der nId entsprechen. Funktioniert letztlich wie ein Filter. Der Ausdruck muß einem Indexausdruck genügen. DbGoTop() und DbGoBottom() berücksichtigen das Scope. DbClearScope() hebt es wieder auf. Der Vorteil gegenüber Relationen besteht darin, daß eine Datensatzmenge entsteht. Wichtig ist, vor dem Setzen des Scopes die Tabelle zu selektieren. Man kann auch Ober- und Untergrenzen für den Scope setzen:

Code: Alles auswählen

DbSetScope(SCOPE_TOP,"1")
DbSetScope(SCOPE_BOTTOM,"4")

setzt einen Scope, wobei nur Datensätze angezeigt werden, dessen führender Index die Werte "1" bis "4" zurückliefert. Ist nur ein Beispiel und mag im Alltag in dieser Form weniger taugen.

Beitrag von **Martin Altmann** » Fr, 12. Mai 2006 18:14

Hallo Tom,
wie setzt man denn einen Scope, wenn die ID 87897 oder 878768 oder 12334 oder 767634 sein darf (also mehrere CDs markiert werden können sollen)?
Dafür muss man dann doch mit Set Filter arbeiten, oder?
Dann ginge das mit den Arrays sicherlich schneller (wenn auch wahrscheinlich nur gering), weil nicht immer wieder aufs Neue auf die Datenbanken zugegriffen werden muss...

Viele Grüße,
Martin

Beitrag von **Manfred** » Fr, 12. Mai 2006 18:20

Ich mache jetzt mal einen Rundumsschlag

@Martin,
ich arbeite im hybridmodus und weiß gar nicht, ob das so geht, wie Du mir das hier netterweise vorschlägst. Ich habe zwar schon ein paar Sachen auf GUI umgestellt, XbpBrowse für DBanzeigen und Confirmbox usw. aber das Hauptprogramm läuft immer noch im Textmodus. Wird auch noch solange bleiben, bis ich mich sicher fühle die komplette Anwendung umzustellen, bzw. bis diese Anwendung hier richtig läuft, im Betrieb ist und ich Zeit und Ruhe finde mich mit GUI auseinanderzusetzen.
Deshalb habe ich auch nur den Ausschnitt des Bildschirmes, den ich ganz am Anfang für das Textprogramm angegeben habe. (Oder gibt es da doch noch einen Trick, wie man GUI Fenster zusätzlich über den Rahmen hinaus angezeigt bekommt? Wäre aber auch unnütz, weil das Fenster eh schon auf 1024x768 läuft und somit den kompletten Bildschirm benutzt.
Mit anderen Worten, Listboxen und all die schönen Dinge habe ich unter Xbase++ noch nie benutzt und habe ich auch noch keine Ahnung von. Leider. Ärgerlich.

@Tom,

an den Index ID und Titel habe ich auch schon gedacht, aber wie schon weiter oben erklärt geht es nicht, weil es nicht immer mehrmals die gleiche ID gibt, innerhalb derer man dann noch den Titel packen könnte.

@Hubert,

Callback-Codeblock? Ich hoffe das ist keine Ferkelei? Habe ich mich noch nie mit beschäftigt. Muß ich also nachsehen und mich reinknien.

Nochmal @Tom,

das mit dem Dbsetscope hatte ich schonmal kurz probiert, aber wie schon erwähnt vor die Wand gefahren, weil ich das irgendwie nicht so ganz gefressen kriege. Ich habe mal kurz versucht etwas zu "filtern", aber es klappte nicht. Also auch Neuland für mich. (verflixt)
Vor allen Dingen, wie sieht denn das Ergebnis dann aus?

Weiah, ich kriege nochmal die Motten.

Beitrag von **Manfred** » Fr, 12. Mai 2006 18:24

Hi Martin,

jetzt war ich zu ausschweifend mit der letzten Antwort.

Also:

Es müssen nicht mehrere CDs ausgewählt werden.
Es geht nur darum sie anzuzeigen und dann 1 auszuwählen, mit der dann weitergearbeitet wird.

Aber diese Anzeige sollte dann die Titel sortieren und dann noch Bestand vom Nichtbestand trennen und nur die anzeigen, die einen Bestand haben.

manoman, wenn ich das alles vorher gewußt hätte, dann hätte ich bei der 0ten Normalform oder so aufgehört

Beitrag von **Manfred** » Fr, 12. Mai 2006 18:29

Jetzt ist mir auch gerade kurz eingefallen, wie das mit den SQL Datenbanken gemacht wird. Es wir das Ergebnis Feld für Feld in eine neue Db geschrieben, oder in ein Array, da ja dann alles untereinander doppelt und dreifach, bzw. jeder Titel oder so in jeder Zeile erneut angezeigt wird. Das wäre dann sicherlich eine Möglichkeit es mit einem passenden Array zu machen. Die Felder, die angezeigt werden sollen, stehen in einer passenden Maskendatei, die zu jedem entsprechenden Browse vorher geladen und ausgewertet wird.

Sicherlich wäre das wohl die beste Lösung.

Hm, das wird wieder ein Wochenende werden......

Beitrag von **AUGE_OHR** » Fr, 12. Mai 2006 19:03

hi,

Martin Altmann hat geschrieben: wie setzt man denn einen Scope, wenn die ID 87897 oder 878768 oder 12334 oder 767634 sein darf (also mehrere CDs markiert werden können sollen)?

nope, da muss man "zerpflücken" und jede inzel betrachten.
siehe eine SCOPE einfach als SEEK an. Wenn ein SEEK()
funktioniert dann geht auch ein SCOPE.

Dafür muss man dann doch mit Set Filter arbeiten, oder?
Dann ginge das mit den Arrays sicherlich schneller (wenn auch wahrscheinlich nur gering), weil nicht immer wieder aufs Neue auf die Datenbanken zugegriffen werden muss...

ein SEEK wird immer schneller sein als ein "SetFilter".

Array ist gut, aber wie Tom schon sagte evtl. ein Problem bei
Mehrbenutzerbetrieb.

gruss by OHR
Jimmy

Beitrag von **AUGE_OHR** » Fr, 12. Mai 2006 19:38

Manfred hat geschrieben:
Martin Altmann hat geschrieben: Aber Du kannst ja natürlich auch mehrere parallele "Browses" aufbauen - jedes enthält nur ein Typ.
GENAUSO, PRIMA,

aber wie macht man sowas? Das wäre natürlich total heiß, in dem einen Browser scrollen und der andere führt mit. Aber absoklut keine Ahnung wie das klappt. Ich habe auch schon mal in den Beispielen nachgesehen, aber keinen Schimmer davon.

Und dann natürlich hin und herspringen und im erlaubten Fenster mit RETURN, oder so übernehmen zur Weiterverabeitung

alles in Codeblocks packen und bei :stable den Codeblock evaluieren

Code: Alles auswählen

bBlock := {|| BroKunden(ID_NR , nBP) }

Cl*pper :
   DO WHILE lMore
      nKey := 0
      DO WHILE (nKey := INKEY()) == 0 .AND. !aoBrowse[nBP]:stabilize()
      ENDDO
      IF aoBrowse[nBP]:stable
          IF bBlock <> NIL
              EVAL(bBlock)

Xbase++ :
nEvent := xbe_None
DO WHILE .NOT. lExit
   nEvent := AppEvent( @mp1, @mp2, @oXbp)
   IF bBlock <> NIL
      EVAL(bBlock)

Im Cl*pper Beispiel siehst du auch schon den Ansatz für eine "multi"
Browse. Jedes Browse wird in einem Array "verwaltet" und per Index
[nBP] umgeschaltet.

Ich habe hier eine ähnliches Cl*pper Demo ... soll ich das uploaden ?

nun zu dem "Relation" / "Scope" Thema : Also in dem Codeblock
rufe ich ja BroKunden() mit dem Parameter ID_NR welches als
"Relation" gelten soll.

Code: Alles auswählen

PROCEDURE BroKunden(cSeek_ID, nBP)
STATIC old_id
IF old_id == cSeek_ID
    RETURN
ENDIF
SELECT ...
SEEK(cSeek_ID)
IF FOUND()
    SET SCOPETOP       TO cSeek_ID
    SET SCOPEBOTTOM TO cSeek_ID
    Element[nBP]:RefreshAll
...
ELSE
    SET SCOPE TO
...

wenn du nun "multi" Browse hast must er beim EVAL() eben per
FOR/NEXT alle Elemente durchlaufen.

gruss by OHR
Jimmy

Beitrag von **brandelh** » So, 14. Mai 2006 23:03

Manfred hat geschrieben:
ich arbeite im hybridmodus ... läuft immer noch im Textmodus

@Hubert,

Callback-Codeblock? Ich hoffe das ist keine Ferkelei? Habe ich mich noch nie mit beschäftigt. Muß ich also nachsehen und mich reinknien.

Hallo Manfred,

Schweinereien sind das nicht, sondern die Steuerungsfunktionen der XbpParts. Wenn du im Textmodus arbeitest, brauchst du TBrowse bzw. Browse() damit habe ich schon ewig nicht mehr gearbeitet.

Wenn du einen TBrowse mit Arrays brauchst, kann ich in meinen Archiven suchen, kann aber etwas dauern. Bitte wenn gewünscht kurz mitteilen.

Beitrag von **Manfred** » So, 14. Mai 2006 23:08

Hi Hubert,

die Anzeige von Daten machen ich schon über XbpBrowse(). Das gefällt mir schon rein optisch besser, als der Textmodus.

Beitrag von **brandelh** » So, 14. Mai 2006 23:13

Hallo Manfred,

wenn es um reine Anzeige geht ist der XbpQuickBrowse() eventuell besser:
schneller, aber nicht so flexibel.

Beitrag von **Manfred** » So, 14. Mai 2006 23:21

Hubert,

werde ich Morgen einmal näher ansehen. Das Beispiel mit dem Suchen in dem Browse macht mich neugierig.

Ich hatte schon mal einen Blick darauf geworfen, konnte aber auf die Schnelle nichts damit anfangen.

Beitrag von **Manfred** » Mi, 17. Mai 2006 13:13

So,

dass ursprüngliche Problem ist gelöst. Den Teil, der die RELATIONEN Probleme unter Xbase++ bringt, habe ich mit DBSEEK() gelöst und der Rest wird über RELATIONEN verbunden. Das klappt so. Das gewünschte Ergebnis schreibe ich in eine temporäre DB und werte es dann aus. Klappt ganz gut

Auch hier wieder:

Dank an alle, die sich mit Rat und Tat beteiligt haben.

PS: Die einzelnen weiteren Vorschläge von euch, werde ich noch zu anderer Zeit ausprobieren.