index on descend

[MatthiasF]

Ich habe da eine alte gekaufte clipper Lagerverwaltung (keine Quellen, kein Support mehr, ist wie sie ist) die ich noch eine Weile behalten muß. Ich stricke da immer Schnittstellen zu Kunden dran und gut ist.
Ich habe jetzt eine meiner Schnitstellen auf xBase umgestellt und habe Schwierigkeiten mit einem Index der ein descend enthält.
Die Lagerverwaltung baut diesen Index so auf:

Code: Alles auswählen

index on descend(RICHTUNG + str(KUNDE,6,0) + AUFTRAGNR) to INDEXNAME

Dabei kommt ein NTX Index heraus.
Wenn ich mit meiner Schnittstelle etwas in diesem Index suche, sieht das so aus:

Code: Alles auswählen

seek descend("A" + "700000" + "    4711")

Und das funktioniert auch, immer, 100 mal am Tag, seit zwei Jahren. Wenn ich meine Schnittstelle mit xBase compiliere und linke, findet sie in diesem Index nichts mehr.
Die Gegenprobe habe ich auch gemacht: Wenn der gleiche Index mit xBase erzeugt wurde, findet die Schnittstelle den Auftrag, aber die Lagerverwaltung nicht mehr.
Probeweis habe ich das auch mit Indexen probiert die kein descend enthalten, da funktionierte scheinbar alles in beide Richtungen.
Wie komme ich da drumherum ?
Wie gesagt: An der Lagerverwaltung ist keine Änderung möglich, sequentielle Suche geht auch nicht.

[brandelh]

Hallo,

ich vermute es liegt an dem LOCKOFFSET.

Unter Clipper war der Anfangs 1GB und später konnte man dies mit einem OBJ auf 2GB einstellen. Xbase++ nutzt den höheren Wert - dachte ich, aber in der Hilfe steht 1GB drin.

Egal, lies in der Hilfe bei DBFDBE, BTXDBE und DbeInfo() zu dem Wert DBFDBE_LOCKOFFSET nach und frage ab, welchen Offset die original DBF Datei nutzt. Sowohl Index als auch DBF müssen gleich sein.

PS: wenn möglich immer Xbase++ zum Indexaufbau nutzen, da einige Clipperfehler beseitigt wurden.

[brandelh]

Hi,

du kannst natürlich auch mal bei Xbase++ und Clipper einen Test machen:

? "-"+(dein Indexbegriff mit descend)"+"

und jeweils in Clipper und Xbase++ testen ob das gleich ist ...

[MatthiasF]

Erstmal Danke für die schnelle Antwort, wie gesagt das alte Programm kann nicht verändert werden. Mit dem Offset werde ich mich am Wochenende versuchen.
Und was sagt mir das:

? "-"+(dein Indexbegriff mit descend)"+"

Ich soll auf den Bildschirm ausgeben:

Code: Alles auswählen

? ">" + descend("A700000    4711") + "<"

• clipper:>¿ÉÐÐÐÐÐààààÌÉÏÏ<
  xBase:>¿ÉÐÐÐÐÐààààÌÉÏÏ<

Habe mir auch schon mal die verschiedenen Index Dateien mit Hex Editor angesehen. Die header weichen geringfügig voeinander ab. Das zweite Byte ist unterschiedlich und hinter dem Indexausdruck steht bei xbase der Name des Indexes drin. Und auch in dem Teil wo es so aussieht: ¿ÉÐÐÐÐÐààààÌÉÏÏ sind ein-zwei Abweichungen.

[brandelh]

Und was sagt mir das:

? "-"+(dein Indexbegriff mit descend)"+"

Ich soll auf den Bildschirm ausgeben:

Code: Alles auswählen

? ">" + descend("A700000    4711") + "<"

• clipper:>¿ÉÐÐÐÐÐààààÌÉÏÏ<
  xBase:>¿ÉÐÐÐÐÐààààÌÉÏÏ<

die Indexbegriffe sehen gleich aus oder ?

Also vermute ich den Zusammenhang beim LOCK Offset.

Nutzt du eigentlich eine eigene DBESYS.PRG ?

[Rolf Ramacher]

Hi Matthias,

nutzt du den NTX aus clipper oder setzt du in xbase neu? Versuch dochmal cdx-Index in xbase vor der Suche neu zu setzen, ob dies klappt

[AUGE_OHR]

hi,

Code: Alles auswählen

index on descend(RICHTUNG + str(KUNDE,6,0) + AUFTRAGNR) to INDEXNAME

Dabei kommt ein NTX Index heraus.

Welche Xbase++ Version ?
ich fürchte du bist zum DESCEND() Bug gekommen ...
suche mal im Alaska Forum.

[AUGE_OHR]

hi,

clipper Lagerverwaltung
Die Lagerverwaltung baut diesen Index so auf:

Code: Alles auswählen

index on descend(RICHTUNG + str(KUNDE,6,0) + AUFTRAGNR) to INDEXNAME

Wenn ich meine Schnittstelle mit xBase compiliere und linke, findet sie in diesem Index nichts mehr.
Die Gegenprobe habe ich auch gemacht: Wenn der gleiche Index mit xBase erzeugt wurde, findet die Schnittstelle den Auftrag, aber die Lagerverwaltung nicht mehr.

Mir fiel eben noch ein das sich Xbase++ Descend() noch einen 2nd
Parameter hat für Cl*pper compatibilität.

Help File : Descend()

Syntax

Descend( <Expression> [,<lCompatible>] ) --> DescendValue

Parameter

<Expression>

<Expression> ist ein beliebiger Ausdruck, der einen Wert mit Datentyp Zeichen, Datum, logisch oder numerisch haben kann.

<lCompatible>

Wird für <lCompatible> der Wert .T. (wahr) angegeben, so wird bei Zeichenketten die SET COLLATION Einstellung ignoriert. Das entspricht Clipper kompatiblem Verhalten. Der Standardwert ist .F. (falsch), d.h. die Funktion Descend() berücksichtigt die SET COLLATION Einstellung.

[MatthiasF]

Erstmal Asche auf mein Haupt:
Ich war ein paar Tage nicht da und dann habe ich die Antwort von AUGE_OHR glatt übersehen, hatte den Haken nicht gesetzt.

Ich habe ein paarmal hin und her probiert, es funktioniert:
Alt:

Code: Alles auswählen

 index on descend(&ausdruck) to &index

Neu:

Code: Alles auswählen

index on descend(&ausdruck,.T.) to &index

Danke für die Hilfe ! EINE Kompatibilitäts Baustelle weniger.

[MatthiasF]

Ich muß dieses Thema leider nochmal aufwärmen:
Bislang habe ich in diesem descend index nur gesucht. Dank des Parameters .T. für kompatible suche finde ich auch was. Prima !
Jetzt habe ich es mit einer Schnittstelle zu tun die auch mal Sätze anhängt und schon ist das alte Problem wieder da: Meine Lagerverwaltung findet die neuen Sätze nicht.
An der Lagerverwaltung mit ihren ganz normalen Clipper Indexen (.NTX) ist KEINERLEI drehen möglich.
Die Frage wäre also: Wie mache ich xbase klar, das es ein solcher (kompatibler) Index ist ?
Etwa sowas:

Code: Alles auswählen

append blank, <compatible>

oder

Code: Alles auswählen

replace FIELD with AUSDRUCK,<compatible>

Gibts das ?

[Jan]

Matthias,

was meinst Du denn mit .T.=Kompatibel beim Seek? Sagt mir garnichts. Und wenn der Index wie von Jimmy angeführt kompatibel erstellt wurde, müsste doch eigentlich auch jeder Append etc. kompatibel durchgeführt werden.

Hast Du denn mal DbAppend() versucht? Hat zwar auch den von Dir angesprochenen Parameter nicht, aber da ich den ohnehin nicht kenne...

Ich selber hatte noch nie Probleme mit Indizee zwischen Clipper und Xbase++, trotz einiger manchmal etwas älterer Projekte (auch mal mit Descend).

Jan

[AUGE_OHR]

hi,

Meine Lagerverwaltung findet die neuen Sätze nicht.

in der Beschreibung von Descend steht :

Wenn eine Index-Datei angelegt wurde, die Descend() in ihrem Index-Ausdruck enthält, muß später bei SEEK oder DbSeek() der Suchwert auch mit Descend() aufbereitet werden.

[MatthiasF]

Mann, seit Ihr fix.
@jan

Und wenn der Index wie von Jimmy angeführt kompatibel erstellt wurde, müsste doch eigentlich auch jeder Append etc. kompatibel durchgeführt werden.

Genau das tut´s aber nicht, jedenfalls nicht mit default Werten.

@auge_ohr:
Es geht gar nicht mehr um die Suche mit dem xbase Programm.
Die Datendatei ist offen, die mit index on descend(AUSDRUCK,.T.) erstellte Indexdatei ist auch offen. Die alte Applikation findet den AUSDRUCK, das xbase Programm auch. Alles schick, läuft seit einiger Zeit. Danke nochmal.
Nun möchte ich mit dem xbase Programm einen Satz anhängen, das macht dieses (jetzt mit xbase compilierte) Programm seit einigen Jahren mit append blank, dann befülle ich die einzelnen Felder mit replace (Logo: Datei und Index sind offen). Der Erfolg ist, daß die alte clipper Applikation den AUSDRUCK nicht mehr findet. Also muß ich doch irgendwie dem append oder dem replace sagen, daß es sich um einen solchen alten clipper Index handelt.
Muß ich mit dem SET COLLATION rumspielen ? Wenn ja: Wie, auf welche Werte ?

[brandelh]

Hi,

append blank und replace etc. verhalten sich zumindest bei der DBFDBE genauso wie Clipper, aber nicht die Indexdateien.

Beim Speichern der Daten wird der Index für den neuen Satz erzeugt, und zwar mit dem Macro, der als Befehl in die Indexdatei bei der Erstellung eingefügt wurde:

...descend(...

nun müsste aber in Xbase++ descend(..., .t. ) aufgerufen werden, um die Verwendung der SET COLLATION Einstellung auszuschalten.

Das steht so in der Hilfe drinn und auch der Hinweis, dass man bei Clipper genau diese Änderung machen soll. Soweit ich dich verstanden habe, habt Ihr aber den Quellcode nicht mehr.

Nun könnte man natürlich hingehen und die SET COLLATION so einstellen, dass sie genau gleich ist zu Clipper ... ist wohl eh besser.

Binde bei dir die DBESYS.PRG ein und ändere dort auf

SET COLLATION TO ASCII

weiterhin könnte auch ein Problem des längeren Refresh vorliegen, also immer nach dem Speichern

dbskip(0)

aufrufen.

[brandelh]

Hi,

ich meine es gab natürlich auch unter Clipper die Möglichkeit die
Sortierfolge zu ändern irgendwas mit NTX_OBJ etc. Dateien die man linken konnte.

Du müsstest also zunächst auch feststellen, ob im Clipperprogramm sowas gemacht wurde (Sortierfolge ABCD...abcd oder AaBb etc. wo stehen Umlaute ... U,UE,Ü.. oder ganz wo anders.)

[brandelh]

nun müsste aber in Xbase++ descend(..., .t. ) aufgerufen werden, um die Verwendung der SET COLLATION Einstellung auszuschalten.

bin ich blind ... DU kannst doch die Indexdateien mit Xbase++ und dem 2 Parameter erzeugen und Clipper wird genau diesen Ausdruck bei jedem Öffnen übernehmen und auch beim Anlegen neuer Datensätze benutzen.

Im Clipperprogramm braucht man dann auch nichts ändern.
Zeichensatz und Collation sollten dennoch in beiden übereinstimmen !

[MatthiasF]

Hallo Hubert,
also an den alten Clipperquellcode ist definitiv nicht mehr ranzukommen, vor Jahren Programm gekauft, Firma nicht mehr da, Mitarbeiter in alle Winde zerstreut. Ich vermute jedoch, daß dort nichts hinsichtlich der Sortierreihenfolge rumgespielt wurde. Meine Schnittstellen und sonstige Prgrammchen, die auf diese Daten zugreifen, benutzen nur Standareinstellungen und es gab nie Probleme.
Ich habe mit set collation to ascii geteste und es lief sofort, bei der Gegenprobe lief es nicht mehr. Das ist dann wohl die Lösung. Und eine sehr einfache obendrein.

Danke wiedermal an alle.