Suche in großen Datenbeständen

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Servus,

typisches Szenario, Artikel-DBF mit > 1 Mio Datensätze, suche in 2 Textfeldern nach einem Schlagwort. Netzwerk, kein ADS oder SQL, wie macht ihr das ohne lahmen Filter im Browse / Quickbrowse?
Index auf die 2 Textfelder gibt es, scope und ordwildseek() kommen aber nicht in Frage, da ja so wie

Code: Alles auswählen

set filter to cSuchText $ upper(art->text1) .or. cSuchText $ upper(art->text2)
gesucht werden soll.

Danke!
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Suche in großen Datenbeständen

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben:Index auf die 2 Textfelder gibt es, scope und ordwildseek() kommen aber nicht in Frage, da ja so wie

Code: Alles auswählen

set filter to cSuchText $ upper(art->text1) .or. cSuchText $ upper(art->text2)
gesucht werden soll.
wenn du auf 2 Felder Type "C" suchen willst sollte der Index über beide Felder gehen

Code: Alles auswählen

INDEX ON upper(art->text1+art->text2) TO $$$SUCH
Ordwildseek(*ALLO*XBASE*)
DO WHILE FOUND()
...
   Ordwildseek()
ENDDO
wenn du allerdings von MEMO Feldern spricht ...
gruss by OHR
Jimmy
Benutzeravatar
Wolfgang Ciriack
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2932
Registriert: Sa, 24. Sep 2005 9:37
Wohnort: Berlin
Hat sich bedankt: 13 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von Wolfgang Ciriack »

Es gab auch mal von Alaska in Solutions ein full text search in einer Datenbank (APS.LIB und .DLL), könnte man mal ausprobieren.
Viele Grüße
Wolfgang
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Servus Jimmy,

danke für den Hinweis. Also rauskopieren (das geht ja wunderbar mit dbexport) in eine Temp-DBF (array schwierig, weiß ja nicht, wieviele Treffer es gibt), diese dann gesondert quickbrowsen und mittels Doppelklick zurück ins ursprüngliche Browse mit dbgoto(nSatznr)?

Weißt Du da eine Möglichkeit, wie ich die Dauer des Vorgangs korrekt in einem Progressbar anzeigen kann?

Filter ist schon sehr bequem, da bräuchte ich den Umweg über eine Temp-Dbf und die ganze GUI-Funktionalität nicht machen, ist aber halt auch zu langsam.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Wolfgang Ciriack hat geschrieben:Es gab auch mal von Alaska in Solutions ein full text search in einer Datenbank (APS.LIB und .DLL), könnte man mal ausprobieren.
Danke, liegt schon seit Zeiten auf der Festplatte, völlig unbeachtet. Die Dokumentation dazu ist leider extrem spärlich, muss ich mir mal genauer ansehen.

Danke.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

Bei mir hat die Fulltextsearch nicht funktioniert.

Ich würde z.B. 50 bis 100 Treffer in einem Steuerarray (nur RecNo oder RecNo + Text) sammeln und das skippen bzw. die ganze Anzeige über dieses Array erledigen.
Außer man will nachher prüfen können was angezeigt wurde, dann ist die externe Datei sinnvoll.
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Servus Hubert,

das Array dann als Skipblock für das Quickbrowse? Geht das?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Ein OrdwildSeek() dauert ca. 20 Sekunden, bis der erste Treffer gefunden wird. Das bei 1 Gbit-Leitung zum Server, ein Benutzer, 700000 Datensätze, sonst läuft nichts.
Da ist ein Filter im Quickbrowse sehr viel schneller, wenn viele Suchbegriffe gefunden werden. Da hab ich nach ein paar Sekunden bereits Treffer.
Der Unterschied hier ist: Das OrdwildSeek braucht immer ca. 20 Sekunden für den ersten Treffer und dann je nach Anzahl.
Der Filter zwischen 2 - 600 Sekunden, bis das Quickbrowse wieder stabil ist...

Also alles in allem nicht viel Unterschied. Die Möglichkeiten sind mit OrdwildSeek größer und ich kann schneller Ergebnisse anzeigen.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Suche in großen Datenbeständen

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben:Ein OrdwildSeek() dauert ca. 20 Sekunden, bis der erste Treffer gefunden wird.
hm ...so was habe ich schon mal gehört ... das ist bei meinen Index ( 6 Felder ) nicht der Fall ...
liegt es vielleicht am "Inhalt" ... ich suche nach (Telefon/Rechnung/Kto.) Nummern im String.

das "APS" von Alaska benötigt IMHO den EXCLUSIVE Mode ... im Netzwerk "so" kaum zu gebrauchen
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Nein, dürfte es nicht, die 2 Felder sind je 40 Zeichen, der Index upper(text1) + upper(text2). Klar sind viele ähnliche Texte im Index, bei 1 Mio Artikeldatensätzen, die größtenteils aus Datanorm-Einlesungen stammen. Hab hier z. B. Elektro-Daten und die Suchbegriff ist z. B. "Stromerzeuger". Kommt ca. 50x vor.

Die dbseek-Zeiten sind ganz normal, im Netz < 0.1 Sekunde.

Wäre da eigentlich ein upper(text1 + text2) schneller?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

Bei mir war OrdWildSeek() immer sehr schnell, ich habe damit Namen durchsucht (Portugiesen haben keinen fixen Vor- und Nachnahmen, die Reihenfolge ist beliebig und die Gewichtung gleichberechtigt.).
ABER ...
Ein OrdwildSeek() dauert ca. 20 Sekunden, bis der erste Treffer gefunden wird. Das bei 1 Gbit-Leitung zum Server, ein Benutzer, 700000 Datensätze, sonst läuft nichts.
das schreit nach einer SQL Server Lösung !
Auch OrdWildSeek() muss die Indexdatei komplett durchsuchen, bei vielen übersprungenen Sätzen und langen Indexbegriffen geht da viel Holz über die Leitung.
Auch ein 1 GB Netz ist empfindlich gegen Konkurenz und alles trifft sich auf der Leitung zum Server.
Bei einem SQL Server mit z.B.: SQLExpress() könntest du die Anzahl der Datensätze und Felder genau auf die nötige Anzeige beschränken und hättest auch keine Indexfehler mehr zu fürchten.
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Hubert,

da stimme ich Dir 100%ig zu. Aber Arctica ist immer noch nicht released... Ich habe die Standard-Subskription (schon 2x ohne jegliche Updates) und jetzt seit der "Einführung von Arctica 2010" :roll: noch ein externes Produkt zu kaufen...
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

Nun JA, Arctica kann das natürlich ... legt aber den Server auf PostGreSQL fest.
Das muss kein Nachteil sein, aber SQLExpress ist seit Jahren stabil und kann mit jedem umgehen (ODBC).
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von Tom »

Instring-Suche bei > 1 Million Datensätzen, Netz. Keine sehr schöne Ausgangssituation ohne Datenbankserver. :(

Im normalen XbpBrowse dürfte SET SMARTFILTER ON helfen, die Anzeige etwas zu beschleunigen, jedenfalls die nach dem ersten Aufbau des Browses. Smartfilter bewirkt, dass sich das Workarea-Objekt die Datensätze merkt, für die die Filterbedingung zutrifft, den Filter also pro Datensatz nur einmalig evaluiert. Damit wäre schon ein bisschen was gewonnen. Der Smartfilter funktioniert übrigens auch fehlerlos. Man sollte nur nicht vergessen, ein DbRefresh() für die Workarea auszulösen, wenn sich Filter oder Datenbestand (mutmaßlich) geändert haben.

Aber ich fürchte, ohne Designänderung kommst Du da nicht voran. OrdWildSeek() ist in solchen Szenarien auch nicht viel schneller als ein "nackter" Filter. Es soll nach Schlagworten gesucht werden. Warum dann eine Instring-Suche? Sind die Schlagwörter innerhalb der Tabellenfelder konkatiniert? Wenn nein, könnte man Indexe für die (verschiedenen) Felder anlegen und direkt - über die normale Indexsuche - suchen. Da ein doppelter Scope (auf mehrere Felder zugleich) nicht möglich ist*, müsste man das Ergebnis der Suchoperation(en) in ein Array umschichten und in der Tabelle dann das Array browsen, wobei die Datalinks der Spalten wiederum auf die Tabelle verweisen müssten. Um dafür zu sorgen, dass sich die Tabelle mit dem Array synchronisiert, müsste der Datalink der ersten Spalte das notwendige DbGoto() enthalten. Vorsicht bei Tabellen mit SetLeftFrozen(). Da funktioniert dieses Modell manchmal nicht richtig.

* Doch, theoretisch schon, da die Expression für das Scope natürlich auch eine Funktion sein kann, aber es wäre dennoch ein bisschen kompliziert.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

OrdWildSeek() ist in solchen Szenarien auch nicht viel schneller als ein "nackter" Filter.
um es klar zu sagen, einfach ausgedrückt durchsucht die Funktion die INDEX-Datei sequentiell.
Wenn der Indexbegriff 30 Zeichen und die Satzlänge bzw. restlichen Texte 1024 Byte sind,
braucht es nur einen Bruchteil zu durchsuchen und ist natürlich schneller.
Findet aber auch nur den ersten Treffer, der muss im Array gespeichert werden.
Dann die weiteren ... so ist es bei mir und es funktioniert besser als vorher sequentiell ...

Wenn du aber den Index über die ganzen Felder legst - für diesen Zweck - bleibt die zu durchsuchende Menge identisch.
Bei einem MEMO wird die Sache noch übler, das kann man nur mit $ durchsuchen.
Gruß
Hubert
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Servus Tom,

smartfilter ist standardmäßig auf on und ausgeschaltet habe ich ihn nicht. Die oben genannten Suchzeiten sind also schon mit smartfilter.

Konkatenierte Schlagwörter: Es sollen schon alle Begriffe gefunden werden, also auch "STROM" in "ABB Stotz Fehlerstromschutzschalter". Ich wüsste nicht, wie das anders gehen sollte, entweder filter wie oben geschr. oder OrdwildSeek. Damit sind Deine weiteren Ausführungen hinfällig?

Ein $ - Scope wäre super.

Danke.
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von Tom »

Hallo, Werner.

Damit landest Du vorläufig tatsächlich bei OrdWildSeek(). Es würde wahrscheinlich schon etwas bringen, wenn der Index auf Upper() säße, und dann sollte das Upper() für den Suchtext nicht im Filter (bzw. in der Suchfunktion), sondern vorher für die Abfragevariablen durchgeführt werden (oder schon bei der Eingabe), damit sparst Du auch ein ganz klein wenig Zeit, weil Upper() dann nicht bei jeder Filter-/Suchbegriffsevaluierung ausgeführt werden muss. Mehr fällt mir im Moment auch nicht ein. Man kann natürlich noch tricksen und Teile einer solchen Tabelle in Zeiten der Untätigkeit (beispielsweise in einem Hintergrundthread) lokal sammeln (etwa im Temp-Verzeichnis), um wenigstens nicht im Netz suchen zu müssen. Oder den Index lokal kopieren, auch im Hintergrund. Aber das kann eine Pandorabox werden - und zu fehlerhaften Ergebnissen führen, weil die lokale Kopie natürlich nie wirklich verlässlich aktuell und/oder vollständig wäre.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Suche in großen Datenbeständen

Beitrag von AUGE_OHR »

brandelh hat geschrieben:Bei einem MEMO wird die Sache noch übler, das kann man nur mit $ durchsuchen.
wenn dir die ersten 120/240 Zeichen*** reichen.
***bei CDX je nach DATA Komponente

Code: Alles auswählen

INDEX on SUBSTR(lower(FIELD-MEMOTEXT)+SPACE(240),1,240) TAG MEMOSUCH TO MEMOCDX
OrdwildSeek("*echt*4711*")
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Suche in großen Datenbeständen

Beitrag von Werner_Bayern »

Servus Tom,

danke, das mit dem upper() habe ich eh so, darauf achte ich.

Code: Alles auswählen

Ordwildseek("*" + cText + "*")
Inzwischen hab ich das mit einer Listbox ganz gut umsetzen können, ist jetzt doch wesentlich schneller als mit dbsetfilter. Vor allem, weil ich die Elementanzahl in der Listbox auf 500 begrenzt habe, danach bricht die Suche ab. Ebenfalls wird die Listbox on the fly befüllt, der Benutzer sieht also sofort was und kann schon reagieren, sollte sein Suchbegriff schon bei den ersten Treffern dabei sein. Ab dem Zeitpunkt, ab dem OrdwildSeek den ersten Begriff gefunden hat, geht es ziemlich fix im Netz.

Welcher Index ist schneller?

1. upper(art->text1) + upper(art->text2)
2. upper(art->text1 + art->text2)

Ich tippe - ohne Messungen - auf 2. Funktionalität müsste die Gleiche sein?
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

Wenn du CDX nehmen kannst, sind die Indexdateien kleiner (somit müssen weniger Daten durchs Netz) und du kannst dir UPPER() im Indexbegriff sparen.
Zumindest beim indizieren habe ich immer erhebliche Unterschiede festgestellt sobald Funktionen im Index verwendet wurden.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von Jan »

brandelh hat geschrieben:Wenn du CDX nehmen kannst, sind die Indexdateien kleiner (somit müssen weniger Daten durchs Netz) und du kannst dir UPPER() im Indexbegriff sparen.
Lern ich gerade was neues? Im cdx kann man sich das Upper() sparen?

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Suche in großen Datenbeständen

Beitrag von brandelh »

Hallo Jan,

das hatten wir gestern :arrow: http://www.xbaseforum.de/viewtopic.php? ... 049#p76012

Spiele mal mit dem Beispiel herum und ändere die Zeile:

SET COLLATION TO GERMAN - "satz" wird gesucht und CDX findet "Satz" ... also wie wenn beides auf UPPER() gestellt worden wäre. NTX NICHT :!:
SET COLLATION TO SYSTEM - "satz" wird gesucht und sowohl NTX als auch CDX findet "Satz" ... also wie wenn beides auf UPPER() gestellt worden wäre.
SET COLLATION TO ASCII - "satz" wird nicht gefunden, da nur "Satz" im Feld vorkommt. Case Sensitiv !

Ich meine dass in einem deutschen Xbase++ diese Zeile aktiv ist:

SET COLLATION TO GERMAN

in der Internationalen weiß ich es nicht, steht aber hier:

..\XPPW32\source\SYS\DbeSys.prg
Gruß
Hubert
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Suche in großen Datenbeständen

Beitrag von Manfred »

Hi Hubert,

ich bin mir auch nicht sicher. Ich meine es gibt schon einen Unterschied und wir hätten das Thema vor längerer Zeit schonmal behandelt hier im Forum. Ich finde es aber nicht mehr. Ich benutze auf jeden Fall Upper im Index, weil ich es irgendwann mal ohne probiert hatte und dann stimmte die Reihenfolge nicht mehr.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Sören
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 205
Registriert: Mo, 07. Aug 2006 10:18
Wohnort: Leipzig
Danksagung erhalten: 11 Mal

Re: Suche in großen Datenbeständen

Beitrag von Sören »

Hallo,

die Verwendung der Upper-Funktion in FOXCDX-Indexausdrücken ist nicht notwendig. Schadet aber auch nichts.

Zitat aus der Xbase++ Dokumentation:
Weiterhin ist anzumerken, daß Indizes für Zeichenausdrücke bei der CDXDBE unabhängig von Groß- und Kleinschreibung werden, sobald eine Zeichenvergleichstabelle aktiv ist. Dieses Verhalten ist wiederum kompatibel mit Visual FoxPro.
Beste Grüße,
Sören
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Suche in großen Datenbeständen

Beitrag von Manfred »

OK,

aber wie schon erwähnt, bei mir gab es Probleme. Also zumindest mit Vorsicht zu geniessen.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Antworten