Inoffizielles deutsches Xbase-Forum

Werner_Bayern hat geschrieben: ↑Mi, 18. Okt 2017 21:08 Jan benutzt cdx,

und Xbase++ v2.x
mit der v1.9x kann ist sein Problem "HÄ" vor "HA" nicht nachvollziehen

Werner_Bayern hat geschrieben: ↑Mi, 18. Okt 2017 21:08zu dbfntx hat er sich bisher nicht geäußert.

vermutlich war Alaska nicht an der DBFNTX ... warum auch denn da sind alle erlaubten Datentypen vorhanden.
bei Fox gibt es ja mehr Datentypne die bislang nicht alle von Xbase++ unterstützt wurden und da besteht ja der Bedarf für PolarFox.

das allerdings ausgerechnet die Collation to GERMAN nicht richtig funktioniert ist natürlich peinlich für Alaska

Hallo Jimmy !

das allerdings ausgerechnet die Collation to GERMAN nicht richtig funktioniert ist natürlich peinlich für Alaska

/Ironie on/
Warum denn, die können doch besser englisch als deutsch wie man an der 2.0er Hilfe sieht ...
/Ironie off/

Martin Altmann hat geschrieben: ↑Mi, 18. Okt 2017 11:29warum versuchst Du nicht mittels OrdInfo( CDXORD_COLLATION ) Dein Glück?

Martin,

gibt es dazu irgendwo eine Aufstellung der Rückgabewerte bzw. deren Bedeutung? Ich finde da nirgends was zu. Und bekomme eine 0 zurück ...

Jan

Hallo Jan !

gibt es dazu irgendwo eine Aufstellung der Rückgabewerte bzw. deren Bedeutung? Ich finde da nirgends was zu. Und bekomme eine 0 zurück ...

In der Collat.ch; 0 bedeutet SYSTEM.

Hilft das

collat.ch hat geschrieben:#define COLLAT_SYSTEM 0
#define COLLAT_GERMAN 1
#define COLLAT_BRITISH 2
#define COLLAT_AMERICAN 2
#define COLLAT_FINNISH 3
#define COLLAT_FRENCH 4
#define COLLAT_DANISH 5
#define COLLAT_GREEK437 6
#define COLLAT_GREEK851 7
#define COLLAT_ICELANDIC850 8
#define COLLAT_ICELANDIC861 9
#define COLLAT_ITALIAN 10
#define COLLAT_NORWEGIAN 11
#define COLLAT_PORTUGUESE 12
#define COLLAT_SPANISH 13
#define COLLAT_SWEDISH 14
#define COLLAT_DUTCH 15
#define COLLAT_USER 16
#define COLLAT_ASCII -1

Hans-Peter war schneller...

Viele Grüße,
Martin

Hallo Ihr beiden,

Danke dafür. Hab ich eben gerade auch gefunden. Und bin irritiert - wenn ich die Indizee mit GERMAN neu aufbaue, dann gibt der mir 3 zurück - FInnisch! Ob das vielleicht das Problem ist?

Jan

Was ist daraus geworden?

Uli,

nix ist daraus geworden. Alaska hat das als Fehler anerkannt. Aber noch nichts dran gemacht. Ob die das jemals machen werden steht sicher auch in den Sternen. Ich hab denen schon vor mind. 5 Jahren einen schweren Fehler gemailt, der PDR ist auch immer noch offen.

Jan

Danke für die Info.
Lohnt es sich dann, einen Work around zu programmieren?
Wenn man die Funktion OhneUmlauteStr: Bei der Erstellung des Index nimmt: wird es mit ein bisschen Fummelei funktionieren . Suchen müsste wie folgt gehen: Hilft das?

Edit: habe das gerade ohne zu testen geschrieben.

Hallo Uli,

danke für den Code. Muß ich mal heute Abend oder morgen testen. Im Moment habe ich das einfach mal gelassen wie es war. Bislang hat anscheinend auch noch kein Kunde das Problem real bemerkt ... *uffa*.

Das eine Problem hast Du ja schon ein wenig eingegrenzt - der Indexausdruck muß immer gleich lang sein. Deine Lösung passt das an, produziert dann aber das (mögliche) Problem, das in einem Begriff mit mehreren Umlauten hinten ein gutes Stück im Ausdruck fehlen kann. Da könnte ich mal probieren, den Indexausdruck einfach z. B. 5 Stellen länger zu machen als das eigentliche Feld ist - dann habe ich hinten genügend Platz für Umlaut-Verlängerungen.

Jan

Wenn Du auf Nummer sicher gehen willst, machst Du den Indexstring einfach doppelt so lang wie das Feld .

Auf die Problematik stößt man eh spätestens bei utf-Formaten. Nicht begrenzt auf die Indexausdrücke, sondern Feldlängen allgemein.
Für die SQLer unter euch: Char/Byte ist so ein Beispiel. Wer bisher Byte genommen hat, kann dann ein größeres Problem bekommen.

Viele Grüße,
Martin

Hallo Martin,

die Problematik existiert hier aber leider nicht. Weil Alaska kein UTF in die dbf einbauen will.

Jan

Abwarten. Bis dahin existiert sie für dein Problem nicht, das ist korrekt.

Ich mache das schon immer so, wie Uli das angedeutet hat, führe dafür aber a) gesonderte Felder und b) einen gesonderten Index mit. Dadurch können unterschiedliche Schreibweisen (Möller, Moeller) in Suchfunktionalitäten abgefangen werden, weil sowieso immer nach "Moeller" gesucht werden würde, aber wenn man (meistens intern) exakt weiß, worum es geht, wird auch nur das gesucht - und gefunden. Die gesonderten Felder - auf die dann auch die gesonderten Indexe gehen - sind für DBEs, die keine UDFs in Indexen unterstützen, z.B. ADS. Und, ja, hier ist alles doppelt so lang.

(Edit: Wichtiger als bei Umlauten ist das im Tagesgeschäft erfahrungsgemäß bei allem rund ums ß (Eszett).)

was wäre mit SOUNDEX() ?

AUGE_OHR hat geschrieben: ↑Fr, 10. Nov 2017 18:46 was wäre mit SOUNDEX() ?

• Soundex()
  This function is not supported by Xbase++.
  Description
  Note: A sample implementation of a Soundex algorithm is included in the C-API example programs.

statt SOUNDEX würde ich eher die Kölner Phonetik nehmen. Soundex funktioniert nur für englisch richtig gut.
https://www.jd-engineering.de/german-so ... mentation/

Im Alltag sind es nur Umlaute, das Eszett, die Accent-Kumpels (é, è, ê) und zwei, drei weitere Genossen (je nach Entfernung der dänischen Grenze), die wirklich relevant sind für Ähnlichkeitssuchen, gerade bei Namensangaben. Je komplizierter der Name, umso kreativer werden die Leute bei dessen Schreibung - selbst von meinem 5-Buchstaben-Nachnamen habe ich schon mindestens drei Dutzend Schreibungen gesehen, und die findet man ohnehin nicht alle, ganz egal, mit welchem Algorithmus.

Nicht ganz Tom.
Folgende Varianten tauchen auch gerne auf (eine Zeile jeweils synonym zu sehen):
ck - kk - k
v - w
ou - u
tz - z
ai - ei - ay - ey
Allgemein Doppelungen:
mm - m
nn - n
ss - s
gg - g
ee - e
...
Um nur einiges zu nennen.

Viele Grüße,
Martin