SetScope und Sortierung

[satmax]

Hallo,

Beispiel: ich habe eine Haupttabelle die jeweils mit dem Feld 'NR' mit 2 Subtabellen verbunden ist. In den Subtabellen befinden sich jeweils 1-100 Datensätze die zur Haupttabelle gehören.

Code: Alles auswählen

          Haupttabelle
Subtabelle1   Subtabellen2
Satz1             Satz1
...                 ...
Satz5             Satz20

Das lässt sich mit setscope() ganz leicht darstellen, Ein Browser für die Haupttabelle, je ein weiterer Browser für Subtabelle1 und Subtabelle2.

Ich möchte aber nun die Datensätze aus den Subtabellen jeweils nach einem weiteren Feld sortiert anzeigen. Bewege ich den Satzzeiger in der Haupttabelle sollen die Subtabellen sortiert angezeigt werden.

Wie gesagt, ohne Sortierung ganz einfach mit einem setscope(), aber mit Sortierung?

Datenbank, DBF, Foxpro FTP, und CDX


Gruß
Markus

[satmax]

So geht es:

Code: Alles auswählen

*Index Subtabelle:
STR(NR,10,2)+dtos(termin)+ZEIT

* SCOPE
SUBTABELLE->(dbSetScope(2,STR(HAUPTTABELLE->NR)))

[UliTs]

Schön, wenn man sich dank SQL mit so etwas nicht mehr herumschlagen muß .

Uli

[satmax]

Schön ist wenn es trotzdem geht!

Arbeitest Die mit Xbase++ und SQL, welche DB?

Markus

[UliTs]

Ich arbeite mit xBase++ und dem Advantage DataBase Server (ADS). Als Tabellentyp nehme ich die ADT-Tabellen vom ADS und arbeite mit Data Dictionarys.
Der ADS kann aber auch auf DBF/CDX-Tabellen zugreifen und sogar im konkurrierenden Zugriff mit xBase-Programmen ohne ADS-Benutzung.

Uli

[satmax]

Wie groß ist das der Umstellungsaufwand? Bringt es Performance wenn man mit ADS auf CDX zugreift?

[AUGE_OHR]

So geht es: ...

schön das du eine Lösung hast aber ich frage mich warum du hier kein SET RELATION verwendest ?

Arbeitest Die mit Xbase++ und SQL, welche DB?

du kannst per SQLexpress++ / ODBC oder per API (PostgreSQL, MySQL, SQLlite & ot4xb) native auf SQL Server mit Xbase++ zugreifen.

Die Lösungen erfordern jedoch SQL Kenntnisse da man Query selbst erstellen muss und lediglich ein Result Set zurück erhält.
beide Lösungen arbeiten leider nicht über die DBE ( Alaska : API ) ... und es gibt kein Databinding.
es gibt nicht die gewohnten Db* Befehle zum Navigieren ( DbSeek(),DbGoto(),DbSkip() etc.).
man müsste erst die Daten des Result Set in ein Array "um-schaufeln" ( SQLexpress++ hat DataSet() )



pgDBE, welches mit Xbase++ v2.x erscheint, emuliert den ISAM Stuff und "übersetzt" Db* Befehle in PostgreSQL Query.
damit ist es möglich ein Result Set in einem "normalen" XbpBrowse zu verwenden und auch die Navigation sollte wie gewohnt erfolgen.

wenn man mal dein Problem als Beispiel nimmt ergibt sich mit "alten" Code ein Problem : es dauert ewig ...

Kunden -> Rechnungen -> Einzelne Position -> Lager ...

unter Xbase ( alle Version ) kennen wir beim "öffnen" keine Einschränkung und befinden uns auf dem ersten Record().
nach dem setzten des aktiven Index / Relationen und Bedingungen können wir schnell in der Daten Menge navigieren.

wenn man aber per ISAM Stuff das ganze "so" nachbilden will müsste man bei jeder Navigation beim Kunden eine neue Query
für Rechnungen -> Einzelne Position -> Lager ... schicken / auswerten / darstellen ...

wenn man jedoch den "direkten" SQL Weg wählt könnte man alle Fields in einer SQL Query unterbringen und intern verknüpfen ( INNER / OUTER JOIN )
die SQL Query muss so "genau" wie möglich gewählt sein um eine geringe Datenmenge als Result Set zu erhalten.
mittels eines SQL CURSOR kann man, ab > v9.x, auch LIMIT und OFFSET zusammen mit MOVE verwenden um das Ergebnis
auf die tatsächliche maximal darstellbaren Anzahl von Zeilen für ein Browse zu begrenzen.

[georg]

Hallo, Markus -


im Rahmen des Foren-Treffs werde ich über das Thema MySQL und Migration des Codes sprechen. Manches kann man mit einem guten Editor und Search & Replace erledigen, anderes benötigt Eingriffe in den Code.

Insgesamt ist MySQL (auch von der Syntax her) nicht so schwer zu verstehen.

Die wichtigeren meiner Programme habe ich bereits umgestellt, und ich bin wieder und wieder von der Geschwindigkeit begeistert.

Und kaputte Index-Dateien sind etwas, von dem ich schon lange nichts mehr gesehen habe ...

[satmax]

So geht es: ...

schön das du eine Lösung hast aber ich frage mich warum du hier kein SET RELATION verwendest ?

Arbeitest Die mit Xbase++ und SQL, welche DB?

Ich wüsste nicht wie ich mit SET RELATION die Sortierung der Child-Datensätze lösen könnte?

Danke für Deine ausführliche Erklärung zum Thema SQL. Im Augenblick bin ich froh, mit meiner Umstellung in so kurzer Zeit so weit gekommen zu sein (Clipper auf Xbase++ full GUI). Was praktisch ein Neuschreiben ist/war. Da war für das Thema SQL nicht viel Platz

Mittelfristig werde ich sicher eine SQL Lösung anstreben, wobei meine bevorzugte Variante da der MS-SQL Server wäre (wir haben da schon ein Produkt auf dieser Basis). Grundkenntnisse von SQL sind vorhanden.

@Georg
Leider kann ich noch nicht sagen ob ich zum Forentreff kommen kann, das entscheidet sich erst am Mittwoch.

Gruß
Markus

[AUGE_OHR]

Ich wüsste nicht wie ich mit SET RELATION die Sortierung der Child-Datensätze lösen könnte?

Code: Alles auswählen

SELE 1
USE HAUPTTABELLE
SET INDEX TO ...

SELE 2
USE SubTabelle
SET INDEX TO ...

SELE 1
SET RELATION TO STR(HAUPTTABELLE->NR) INTO SubTabelle

geändert : das TO fehlte ...

[brandelh]

Ich wüsste nicht wie ich mit SET RELATION die Sortierung der Child-Datensätze lösen könnte?

Ein Index kann länger sein als in der Hauptdatei !
Man könnte also ein Feld mit 10 Zeichen in der Hauptdatei und eines mit 20 Zeichen in der Child Datei haben, das ginge, wird aber schnell unübersichtlich und ist bei Änderungen wartungsindensiv.
Man kann aber den Index auch aus verschiedenen Feldern zusammenbauen ...
Angenommen MAIN hat ein Feld ID (die ID - "C" 10 - der MAIN.DBF) und du möchtest, dass die Child-DBF immer die Datensätze zu diesem Fall anzeigt,
aber zusätzlich sortiert nach Rechnungs-Datum (RechDat) ! (Beispiel-code ohne NETERR() Prüfung zur Vereinfachung, real muss der aber rein !)

Code: Alles auswählen

use MAIN alias MAIN
index on ID to MAIN // 10 Zeichen
...
use CHILD alias CHILD
index on ID + dtos(RechDat)
...
select MAIN
SET RELATION TO ID INTO CHILD // ID ist hier das Feld in MAIN, das als Indexsuchbegriff in CHILD verwendet wird.
seek cSuchID

der Befehl "seek cSuchID" in MAIN springt zu dem passenden Satz, wenn dies erfolgreich war, wird mit diesem
Satz auf den ersten Satz in CHILD gesprungen, der cSuchID im Index entspricht, in diesem Beispiel wird er auch das kleinste RechDat haben und alle anderen folgen.

Beispiel mit numerischer ID:

Code: Alles auswählen

use MAIN alias MAIN
index on ID to MAIN // "N" 10, 0 ... ein Feld kann man numerisch indizieren
...
use CHILD alias CHILD
index on StrZero(ID,10,0) + dtos(RechDat) // StrZero() füllt von links mit 0 statt Blank, das ist einfacher beim debuggen (0 kann man leichter Zählen als Blank)
...
select MAIN
SET RELATION TO StrZero(ID,10,0) INTO CHILD // ID ist hier das Feld in MAIN, das als Indexsuchbegriff in CHILD verwendet wird.
seek nSuchID

[satmax]

Hallo Hubert,

Im Prinzip ist das dass gleiche wie ich es mit SetScope() verwende. Ich bin nur überrascht das dies mit SET RELATION funktioniert. Laut Handbuch wird bei SET RELATION ja ein "Hardseek" durchgeführt. Wenn der Index also mit "index on ID + dtos(RechDat)" augebaut ist, die Relation sich aber nur auf die ID bezieht dürfte ja nichts gefunden werden!?

SET SCOPE arbeite da anders, da wird nur der linke Teilstring verglichen.

Jetzt habe ich das mit SET RELATION mal kurz angetestet. Der/die erste(n) CHILD Datensätze stimmen, aber es werden auch alle nachfolgenden ID's angezeigt. IMHO ist das Verhalten nicht wie in der Doku beschrieben sondern ein Softseek. Eventuell habe ich auch noch etwas falsch gemacht, mit dem Debugger habe ich es mir nicht angesehen.

Beispiel Hauptdatei ID 4711 findet mit set relation alle mit ID 4711 (+datum +Zeit) aber auch alle weiteren 4712-....
Mit SET SCOPE habe ich alle 4711 (+datum + Zeit), schön sortiert aber richtiger weise keine 4712-... Datensätze

Hat SET SCOPE in diesem Fall irgendwelche Nachteile im Vergleich zu SET RELATION? Wenn nicht lasse ich es einfach so.


Gruß
Markus

[georg]

Hallo, Markus -


normalerweise sind Index-Dateien als Binärbäume aufgebaut, d.h. der Suchbegriff wird gegen diesen Binärbaum geprüft, bis ein Eintrag gefunden wird. Dieser Eintrag ist LOGISCH nach dem Index-Schlüssel sortiert, d.h. wenn das zweite Feld DTOS(RgDatum) wäre, würde bei mehreren Sätzen, die ausgewählt werden könnten, der Satz genommen, dessen RgDatum das älteste (= kleinste) ist.

Aufgrund der Binärbaum-Struktur kannst Du auch Treffer mit Teil-Schlüsseln erzielen.

[satmax]

Schon, das entspricht Softseek.

Wenn der Index aber so aufgebaut ist:

'STR(aunr,10,2)+dtos(termin)+ZEIT' == " 4711.00201311041200"

Darf doch ein dbseek(STR(aunr,10,2).f.) ==" 4711.00" nichts finden. Laut Doku arbeitet set relation mit softseek .f..


Gruß
Markus

[brandelh]

Im Prinzip ist das dass gleiche wie ich es mit SetScope() verwende.

SetScope() begrenzt auf genau die Zieldatensätze, das tut set relation nicht (man kann in der Relation-DBF mit dbskip() über die Grenzen hinaus springen) !
Je nach Anwendungsfall ist deine Lösung wesentlich sinnvoller !
"Bearbeite alle Rechnungen mit der Kunden-ID xyz" kann man mit SetScope() direkt erledigen, bei set realtion to muss man selbst auf das Ende der aktuellen Kunden-ID achten.

Ich bin nur überrascht das dies mit SET RELATION funktioniert. Laut Handbuch wird bei SET RELATION ja ein "Hardseek" durchgeführt. Wenn der Index also mit "index on ID + dtos(RechDat)" augebaut ist, die Relation sich aber nur auf die ID bezieht dürfte ja nichts gefunden werden!?

Da verwechselst du was ! Ein "hardseek" bedeutet nicht, dass der Suchstring genauso lang sein muss wie der Indexbegriff !
dbSeek() findet auch linksbündige Teilbegriffe.

Code: Alles auswählen

DB->FELD := "ABCDEFG" 
index on FELD
dbSeek( "ABC" , .f. ) => .t. // eof(): .f.
dbSeek( "ABC" , .t. ) => .t. // eof(): .f.

Der Unterschied liegt darin, wenn der Suchbegriff nicht (linksbündig) im Index steht, dann springt "hardseek" auf eof(): .t. und "softseek" auf den Satz, der größer als der Suchbegriff ist.

PS: in einer der 1.8... Versionen war ein Fehler in SET RELATION TO der mir viele Daten zerschossen hat.
Dieser ist jetzt zwar behoben, aber ich nutze es dennoch nicht mehr.

[satmax]

Danke für die Klarstellung, Das mit Hard- und Softseek hatte ich noch nicht so verstanden. War aber in meinem Fall kein Problem da ich verknüpfte Records bei exakter Suche immer nach dem gesamten Indexausdruck suche (Wenn der Index PADL(...) ist, suche ich auch mit PADL(...)).

Aber danke, ich denke da passt bei mir das setScope() ganz gut und ist die optimale Lösung. Gelent habe ich auch wieder etwas...

Gruß
Markus