set relation ohne Index

[saul]

Hallo,
ich möchte eine Relation herstellen in dem sich in einem Parent Feld eine Zahl (Recno() der Chield Datei) befindet, die ich mit der recno() der Chield Datei verbingen möchte.
set index on recno() to test funktioniert scheinbar nicht.

Ich könnte ja ein Feld Recid einbauen, das indizieren und set index on Parent Feld to Chield Recid setzen. Dadurch werden aber die Datenmengen wieder viel größer. Gibt es da einen anderen Weg?

mfg
Wolfgang

[Manfred]

Hi,

kannst Du mal ein bisschen Code zeigen? Das kann ich jetzt so nicht nachvollziehen. Warum sollte das mit dem Recno() Index nicht klappen. Zeig doch mal, wie Du die Relation usw. baust.

[georg]

Guten Morgen, Wolfgang -


erst einmal ein Blick in die Dokumentation:

Code: Alles auswählen

Syntax 

SET RELATION TO [<cRelation1> | <xRecordID1> INTO <cAlias1> ; 
           [TAG  <cTag1>] ] ; 
         [, [TO] <cRelation2> | <xRecordID2> INTO <cAlias2> ; 
           [TAG  <cTag2>]...] ; 
         [ADDITIVE] [SELECT[IVE]]

Zu beachten bitte ich den optionalen Eintrag [TAG <cTags2]...].

Hierzu führt die Dokumentation wie folgt aus:

TAG <cTag>

<cTag> is a string indicating the tag name of the index in the child work area to be used for searching the return value of <cRelation> . If not specified, the tag name of the controlling index of the child work area is used for <cTag> .

Following SET RELATION TO, a list of links can be specified, separated by commas. A call to SET RELATION TO without argument removes all defined links to child work areas from the current work area.

Man kann (!) ein Tag angeben, das verwendet wird, um den Satzzeiger der Child Area zu bewegen. Wird kein Tag angegeben, so wird der aktuell aktive Tag verwendet. Meine Schlussfolgerung ist, dass SET RELATION in der Child Area IMMER einen Index erwartet.

Tag (falls der Begriff nicht geläufig sein sollte) ist ein innerhalb einer Index-Datei gespeicherter Index, der über seinen Namen (eben der Tag) angesprochen werden kann.

Dies gilt, wenn in der Child Area ein Index aktiv ist.

Wenn kein Index aktiv ist, kann die von Dir gewünschte Positionierung so vorgenommen werden:

<xRecordID>

As an alternative to <cRelation> , an expression <xRecordID> can be specified whose value corresponds to a record ID in the child work area. A record ID is a value which uniquely identifies a data record. This value depends on the current database engine (DBE). With the DBFDBE, it is the record number (RecNo()). The synchronization of the record pointer in the child work area then occurs using DbGoto() instead of DbSeek(). This linking is used when no index file is open in the child work area.

Leider findet sich für diesen Fall kein Beispiel, so dass Du mal experimentieren musst.


Die andere Alternative ist, dass Du eine eigene Funktion für die Skips verwendest, und dabei dann den passenden Satz der Child Area anspringst.


Gruss,

Georg

[Jan]

Mußt Du das denn zwingend über eine Relation machen? Ich habe vor längerer Zeit weitestgehend alle Relationen aus meinem Code geworfen. Ursprünglich weil es Hinweise im Forum gab, das die nicht sehr stabil seien. Zur Zeit, weil es bei einem Kunden immer mal wieder Probleme gibt damit, weil ständig zwischen verschiedenen Indizee und Relationen hin- und hergesprungen wird.

In den allermeisten Fällen kann man das auch regeln, indem man das manuel über ein DbSeek() (oder in Deinem Fall DbGoTo(nRecNo)) regelt. Das funktioerit extrem stabil und reibungslos.

Jan

[Manfred]

Das mit den Relationen kann ich so nicht bestätigen. Bei mir läuft das schon seit langem wieder stabil. Aber Dein Problem läßt sich ganz einfach lösen Jan, nicht hin und her springen, sondern einfach das System nutzen und die DBF mehrfach unter anderem Namen öffnen und dann miteinander verknüpfen. Das klappt hervorragend mit Klassen..... Aber wem sage ich das.

[brandelh]

Hallo,

Ein Index auf recno() (also die Funktion, die die aktuelle Satznummer enthält) macht keinen Sinn !

Wenn du nach ihr sortieren möchtest, schalte einfach die Sortierung ab OrdSetFocus(0) (falls ein Index offen ist) oder lass den Index weg.
Wenn du von einem Feld Master->ClientRecID auf die Recno() einer Client-DBF verknüpfen willst,
darf dort nur kein Index aktiv sein.

ABER DAS IST AUCH GEFÄHRLICH !

Wenn in der Client-DBF ein Satz gelöscht und die Datei gePACKed wird, sind alle Verweise falsch !

[saul]

Hallo,
danke für schnellen Antworten.
Ich habe eine Suchroutine, die mir die Datensätze, ca. 40000 nach diversen Einträgen durchsucht. Das Ergebnis lege ich einfach in einer Datei suche.dbf ab in der nur die gefilterten Datensatznummern stehen (Feld satznr). Jetzt möchte ich mit dem R&R Writer einen Ausdruck der zutreffenden Daten machen. Soweit mir bekannt kann ich das in R&R Writer nur über relation machen. Dafür mein Ansinnen ein index on recno() zu machen um dann eine Relation einzurichten,

Code: Alles auswählen

use Daten                       // Datei öffnen
index on recno() to test   // erzeugt einen Indexfile

set relation to satznr into daten   // Relation

Mein Problem liegt wahrscheinlich in der Erzeugung der Indexdatei. Es gibt zwar keinen Fehler aber auch keinen richtigen Index den man nutzen kann.
Da werde ich mit Hilfe Eurer Vorschläge mal weiter versuchen.

mfg
Wolfgang

[Manfred]

Hi,

jetzt muß ich mal ganz dumm fragen: Was verknüpfst Du denn jetzt womit und wie?

[Jan]

Geanu. Für eine Relation braucht man immer 2 Datenbanken. Und wenn man das über "set relation" macht, dann wird von der aktiven Datenbank aus verknüpft. Die ist aber die, die hier verknüpft werden soll. Also Katze beißt sich in den eigenen Schwanz.

Jan

[Tom]

Selbstverständlich kann man einen Index auf RecNo() setzen. Wenn ich das hier mache:

Code: Alles auswählen

USE meinedb NEW
INDEX ON RecNo() to meinedb
SEEK 199

stehe ich anschließend auf Datensatz #199, wenn es ihn gibt. Dieser Index wird auch ordentlich aktualisiert; schließlich kann jeder Indexausdruck beliebige UDFs und Funktionsaufrufe enthalten, und RecNo() ist nichts weiter als eine Funktion, die für die aktuelle Workarea die Datensatznummer ermittelt. Ich sehe da auch keine Konsistenzprobleme, wenn man entweder bei einem DbPack() die Indexe geöffnet hat oder anschließend reindexiert. Deshalb sollte auch eine Relation mit diesem Index funktionieren.

Relationen sind sehr sicher. Man muss nur beachten, dass die Datensatzzeiger für die abhängigen Tabellen erst dann bewegt werden, wenn man diese Tabellen explizit anfasst. Vorsicht ist außerdem bei Verwendung der ADS geboten, die nicht alle Funktionen unterstützt, RecNo() allerdings durchaus.

[Tom]

Ach so: Eine Relation funktioniert natürlich nur mit zwei Tabellen, einen Index muss aber nur die abhängige haben:

Code: Alles auswählen

USE meinedb2 INDEX meinedb2 ALIAS DB2 NEW // meinedb2 enthält ein Feld, das die Datensatznummer von DB1 reflektiert
USE meinedb1 ALIAS DB1 NEW
SET RELATION TO DB1->(RecNo()) INTO DB2
GO TOP // der Datensatzzeiger steht jetzt auf Datensatz 1 von DB1 und auf dem Eintrag von DB2, der dieser Datensatznummer entspricht - sobald ich DB2 "anfasse"

(Ins Blaue; ich arbeite selten mit Relationen und bevorzuge Scopes.)

Für diese Variante muss es auch keinen Index auf "RecNo()" geben, der auch keinen Sinn hätte. Referenziert wird zwar über die Datensatznummer von "DB1", aber diese wird in irgendeinem Feld von "DB2" reflektiert, auf dem der Index steht. Dieses Feld muss dann natürlich auch gepflegt werden, da es sich um eine 1:n-Relation handeln kann (aber nicht muss).

Wie gesagt, Achtung: Ich muss nicht damit rechnen, dass der Satzzeiger in DB2 mit jeder Bewegung in DB1 auch aktualisiert wird. Das geschieht erst, wenn ich explizit auf DB2 zugreife, also ein Feld lese.

Edit: Und noch ein Achtung: Bei diesem Konstrukt müsste ich DB2 immer überarbeiten, wenn DB1 gepackt wird, da sich die Referenz auf die sich dadurch ändernde Datensatznummer auch ändern müsste. Besonders sinnvoll ist das nicht. Man wählt deshalb eindeutige Referenzen, die man selbst vergibt, wenn man so arbeiten will, beispielsweise Auto-Increment-Felder bei FOXDBE.

[georg]

Hallo, Tom -

Ach so: Eine Relation funktioniert natürlich nur mit zwei Tabellen, einen Index muss aber nur die abhängige haben:

Nein, eben nicht. Wenn die abhängige Datei keinen aktiven Index hat, dann wird über recno() verknüpft (siehe mein obiges Zitat aus der Dokumentation).

Aber ich stimme Dir zu, was das Vermeiden von Relations angeht - ich selbst habe in einigen Fällen lieber einen Skipper() geschrieben, der die abhängigen Daten aus der Zweit- (oder Dritt-)Datei durch entsprechende Positionierung dazu holt.

[Manfred]

Es ist eine Frage des Tempos. Wenn man z.B. eine Datei durchläuft und nur ab und an etwas aus einer Verknüpfung benötigt, dann ist es sicherlich effizienter genau dann eine eigene Suchroutine einzubauen, die genau nur dann einen Seek macht, weil dann der Ablauf schneller geht. Wenn man zu jedem Satz etwas benötigt, meine ich festgestellt zu haben, das es egal ist, ob man eine eigene Routine benutzt, oder Relationen setzt. Bzw. könnte es sein, das Relationen etwas schneller sind.

[Tom]

Hallo, Georg.

Du hast recht; es ginge auch eine Relation über die Satznummer ohne Index, dann müsste aber die Referenz (Feld in der steuernden Tabelle) die Satznummer referenzieren. Besonders sinnvoll wäre das aufgrund der aufwendigen Pflege der Datensatznummer in mindestens einer Tabelle aber nicht. Oder die abhängige Tabelle darf einfach niemals gepackt werden.

@Manfred: Relationen haben genau den großen Vorteil, dass in den Kindertabellen nichts geschieht, so lange man sie nicht anfasst. Der Datensatzzeiger wird erst bewegt, wenn man auf die abhängigen Tabellen auch zugreift, vorher tut sich da nüscht. Wenn man beispielsweise automatisch mit jeder Datensatzbewegung in der Haupttabelle einen Scope setzt oder ein Seek auslöst, erfolgt aber mit jeder Datensatzbewegung in der Haupt- auch mindestens eine in der Kindertabelle. Insofern wäre aus Geschwindigkeitsgründen die Relation durchaus das Mittel der Wahl. Steffen hat ja u.a. kürzlich in Hannover ausgeführt, dass man etwa Browses (generell aber Arbeiten mit Tabellen) dadurch beschleunigen kann, dass man die Anzahl der Felder drastisch verringert und alle nicht absolut relevanten Informationen in Nebentabellen auslagert. Für die Arbeit mit solchen Konstrukten empfehlen sich dann eben Relationen, da die Datensatzzeiger in den Nebentabellen nur bewegt würden (also auch nur physikalische Lesevorgänge stattfänden), wenn man darauf zugriffe.

[brandelh]

Selbstverständlich kann man einen Index auf RecNo() setzen.

das hat ja niemand bestritten, aber es macht keinen SINN !

goto 199

trifft immer den 199 Satz, egal ob der Index noch stimmt oder nicht !

Und zum Grundproblem, wenn man kurzfristig - wie beschrieben - die passende DBF mit den RECNOs erstellt hat,
kann man das auch so tun. Nur die Syntax muss stimmen

[brandelh]

@Manfred: Relationen haben genau den großen Vorteil, dass in den Kindertabellen nichts geschieht, so lange man sie nicht anfasst. Der Datensatzzeiger wird erst bewegt, wenn man auf die abhängigen Tabellen auch zugreift, vorher tut sich da nüscht.

möglich dass dies jetzt so ist, aber ich hatte das schon anders erlebt (1.82 oder so...).
JEDER RLOCK() in der Haupttabelle hat die Kindtabellen auf den ersten Satz zurückgesetzt.
War ein Fehler, denn Clipper hat das nicht getan und meine ersen Datensätze waren futsch bis man es bemerkt hat.

[Tom]

Hallo, Hubert.

das hat ja niemand bestritten, aber es macht keinen SINN !

Das habe ich ja auch nicht behauptet. Wobei - wenn Datensatz #199 inzwischen ungültig/gelöscht ist, würde DbSeek(199) ein Eof() = .T. bewirken, was unter bestimmten Bedingungen möglicherweise Sinn haben kann. Im Gegensatz zu DbGoto(199), was ja sogar bei SET DELETED ON zu einem Sprung zu diesem Datensatz führt, selbst wenn er gelöscht ist (okay, dann feuert Deleted() - aber irgendwas ist ja immer). Und DbGoto() ignoriert auch beispielsweise Filter, was DbSeek() nicht tut.

[Tom]

JEDER RLOCK() in der Haupttabelle hat die Kindtabellen auf den ersten Satz zurückgesetzt.

Kann ich nicht bestätigen (für 1.9).

[brandelh]

Der Fehler trat in der 1.80 oder 1.82 auf und wurde dann später behoben, allerdings habe ich seit damals keine Relationen mehr

[Manfred]

Hi Tom,

was ich meinte ist, wenn ich eine DBF komplett durchlaufe und zu jedem Satz eine Info aus einer anderen Tabelle brauche, dann ist es entweder egal, oder aber Relationen etwas schneller. Wenn ich aber eine Tabelle durchlaufe und nur bei bestimmten Voraussetzungen Daten aus einer anderen Tabelle benötige, dann ist ein selbstinstalliertes Seek schneller. Das habe ich in großen Tabellen mehrmals probiert, weil ich es genau wissen wollte. Es wird dann sicherlich damit zusammenhängen, das man halt die Bedingungen vorher geprüft und somit des Auslöser aktiviert hat für die Relation und es deshalb zu diesem Unterschied kam. Ob es jetzt beim einfach Durchlauf auch so ist, das habe ich nicht geprüft. War aber auch nicht wichtig für mich damals.

@Hubert,

es gab mal ein Problem dabei, das hatten wir auch kurz hier im Forum angesprochen. Es wurde dann als Feature auf Wunsch der Kunden verkauft. ich erinnere mich noch leicht bis schwer.

[saul]

Hallo,
entschuldigung, dass ich mich so schlecht ausgedrückt habe.
Dateiname: Daten.dbf
Recno Feld1 Feld2 Feld3...
1 Daten Daten Daten... // 40000 Datensätze
2 Daten Daten Daten..... usw.

Daraus filtere ich die zutreffende raus. und schreibe die zutreffende Recno() in eine zweite Datei such.dbf
Recno Feld1
1 37345 // Feld1 = die DatensatzNr in der Datei Daten.dbf
2 34
3 124 usw.

In R&R Writer wähle ich die Datei such.dbf als Datenbank und drucke die entsprechenden Daten aus der Datei Daten.dbf. Dazu setze ich eine Relation Feld1 in such.dbf auf den Index mit recno() gebildet aus Daten.dbf.

Ich hoffe jetzt ist es etwas klarer.

mfg
Wolfgang

[georg]

Hallo, Wolfgang -


da haben wir uns inzwischen recht weit von Deiner Frage entfernt.

Leider weiss ich nicht, wie R&R damit umgeht.

Da ich grundsätzlich Zeichenindices verwende, würde ich einen Index in dieser Art:

Code: Alles auswählen

INDEX ON Str(Recno(), 10) ...

anlegen und auf diesen Index in R&R verweisen. Das sollte funktionieren. Aus Aktualitätsgründen (es sei denn, Du wendest nie ein DbPack() auf die Datei an) solltest Du den Index vor dem Aufruf von R&R erstellen und gegebenenfalls direkt danach wieder löschen.


Das Problem in dieser Diskussion liegt daran, dass der Hinweis auf R&R untergegangen ist, und dort gelten sicher andere Regeln als unter Xbase.

[brandelh]

Hast du in der DATEN.DBF auch ein Feld mit Namen RECNO ?

Wenn nicht, dann hast du dort wahrscheinlich andere Indexe offen ?
Falls JA, schließen !
Notfalls zusätzlich shared readonly öffnen, OHNE Indexdateinen.

Code: Alles auswählen

DATEN.DBF => normale Felder
SUCH.DBF => Feld: SuchDatenRecNo enthält die RecNo() von den gewünschten Daten aus DATEN.DBF
z.B. 
use SUCH exclusive 
zap // alles löschen
use Daten ... NEW
set index to GewünschteSortierung // falls nötig
do while ! eof()
     if Bedingung() // was auch immer
        such->(dbappend()) // ich prüfe jetzt nicht auf Fehler, da exclusive ... verkehrt wäre es nicht.
        such->SuchDatenRecNO := recno()
     endif
     skip
enddo
set index to 
go top

select such
set relation to SuchDatenRecNO into daten
go top
do while ! eof()
     if such->SuchDatenRecNO # daten->(recno())
        ? "Fehlermeldung"
     else
        ? "gesucht: ",such->SuchDatenRecNO," gefunden: ", daten->(recno()), ... , " OK !"
     endif
     skip
enddo

ich habe das jetzt nicht compiliert, es können also Tippfehler drinn sein, aber so sollte es funktionieren.
Ohne Index auf RecNo()

[brandelh]

Das Problem in dieser Diskussion liegt daran, dass der Hinweis auf R&R untergegangen ist, und dort gelten sicher andere Regeln als unter Xbase.

wohl wahr, oft ist es einfacher eine Zieldatei (DBF oder CSV) zu erstellen und diese zu übergeben