| |
|
|
E.T. | Hallo an alle, ich habe ein (schönes) Datenbankprog, was auch (bis jetzt) wunderbar funktioniert. Nun hab ich aber das Problem, das ich eine Suche über ein numerisches Feld nicht hinbekomme: Ich habe aus der DB einen Index über 4 numerische Felder erstellt (sind Tel.-Nummern drin), das erstellen klappt auch. Wenn ich jetzt im Index mit @dbfind suche, bekomme ich aber keinen Treffer im Index zurück. Wenn ich das gleiche mit dem Index für (Name, Vorname) oder (Geb.-Datum) mache funzt es, nur die blöden Tel.Nummern wollen nicht. Das zuweisen des Index klappt (lt.Rückmeldung) auch, nur wird nix gefunden. Die DB ist geöffnet, der Index erstellt, auslesen der Felder mit den Tel.-Nummern klappt auch. Nur halt das Suchen in diesem Index nicht. JEMAND NE IDEE?? Oder hab ich da mal wieder einen riesigen Denkfehler eingebaut ??? KompilierenMarkierenSeparieren
Proc DS_FindTel
Parameters Number$ Übergabe-String aus Eingabefeld
Declare Tel_Gef&, IDX%
If Left$(Number$,1) = 0 auf führende O prüfen
Number$ = @Del$(Number$,1,1)
EndIF
In folgenden 3 Zeilen hab ich schon probiert:
Spaces vorn, Spaces hinten, 0n vorn, 0n hinten
Auch auskommentiert, ums so zu lassen, wieS ist.
Hat alles nix geholfen, Ergebniss (Tel_Gef&) immer 0 > Nicht gefunden
While (@Len(Number$) < 15) Suchstring-Länge auf 15 setzen
Number$ = + Number$
EndWhile
IDX% = @dbIndex(IDX_Tel) verwendeten Index festlegen
IfNot IDX% FEHLER Index
@MessageBox(Index konnte nicht geöffnet werden !!!,INFO,262144+64)
Else oder weiter....
@dbGo(TOP) zur Sicherheit beim Test eingebaut, auch schon ohne probiert
Tel_Gef& = @dbfind(Number$,1)
Interne Programmier-Kontrolle, nur zur Info, wird dann entfernt
Gleich sieht man, ob was gefunden wurde !!!
Die zu suchende Nummer wird immer korrekt angezeigt (mit Spaces vorn,
hinten, 0n vorn oder hinten oder so wie übergeben, nur ohne führende Null,
je nach dem, was weiter oben in der Schleife gemacht wird (oder auch nicht,
wenn auskommentiert).
@MessageBox(Gesuchte Nummer : + Number$ +
Länge SuchString : + @str$(@Len(Number$)) +
Gefunden JA [1] / NEIN [0] : + @Str$(Tel_Gef&),INFO,262144+16) War noch nie da!!
Case Tel_Gef& : DS_Einlesen wenn gefunden, Datensatz einlesen
EndIf
@dbIndex(IDX_Name) Wieder Standart-Such-Index setzen
EndProc
Hoffe, da kann mir jemand helfen, und hoffe weiter, das mein XProfan10 endlich ankommt.... |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 18.03.2008 ▲ |
|
|
|
|
E.T. | Hallo,
ich glaub, ich habe eben selbst schon was gefunden: Wenn ich die Indexe einzeln erstelle (jedes Feld ein einzelner Index, s.u), kann ich diese auch einzeln durchsuchen und es wird was gefunden. Nun funktioniert aber folgendes nicht, es wird nur der ERSTE Index durchsucht: KompilierenMarkierenSeparieren Das dazupacken von Leerzeichen kann ich mir sparen, hab ich eben bemerkt. Nun ist das durchsuchen mit jedem einzelnen Index ja nicht der Stein der Weisen, kennt jemand ne andere Lösung ??
Mario |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 18.03.2008 ▲ |
|
|
|
|
Thomas Freier | Die Index-Datei wird ja an erster Stelle nicht fürs Suchen benötigt. Mehr für die sortierte Anzeige. Wenn du eine Eingabe in vier dB-Feldern suchst, mußt du bei FIND auch viermal indizieren. Andernfalls SEEK verwenden. Ich denke, dass das automatische Suchen mit einem Befehl in mehreren Datenbankfeldern in keiner Datenbankanwendung möglich ist. |
|
|
| |
|
|
|
E.T. | Bei suche in Indizierten Felden wird nur der erste genommen - man sollte eben auch die Hilfe RICHTIG lesen (Bei mehreren Indices zählt der erste Index). Naja, also Eigentor !! Habs jetzt so gemacht, dann gehts: KompilierenMarkierenSeparieren
Proc DS_FindTel
Parameters Number$ Übergabe-String aus Eingabefeld
Declare Tel_Gef&, IDX%
If Left$(Number$,1) = 0 auf führende O prüfen
Number$ = @Del$(Number$,1,1)
EndIF
Clear IDX%, Tel_Gef&
IDX% = @dbIndex(IDX_Tel_1,IDX_Tel_2,IDX_Fax_1,IDX_Fax_2,IDX_Handy_1,IDX_Handy_2)
ALLE Indexe überprüfen:
CaseNot IDX% : @MessageBox(Index konnte nicht geöffnet werden !!!,INFO,262144+64)
If IDX%
@dbIndex(IDX_Tel_1)
Tel_Gef& = @dbfind(Number$,1)
IfNot Tel_Gef&
@dbIndex(IDX_Tel_2)
Tel_Gef& = @dbfind(Number$,1)
EndIF
IfNot Tel_Gef&
@dbIndex(IDX_Fax_1)
Tel_Gef& = @dbfind(Number$,1)
EndIF
IfNot Tel_Gef&
@dbIndex(IDX_Fax_2)
Tel_Gef& = @dbfind(Number$,1)
EndIF
IfNot Tel_Gef&
@dbIndex(IDX_Handy_1)
Tel_Gef& = @dbfind(Number$,1)
EndIF
IfNot Tel_Gef&
@dbIndex(IDX_Handy_2)
Tel_Gef& = @dbfind(Number$,1)
EndIF
Interne Programmier-Kontrolle, nur zur Info, wird dann entfernt
Gleich sieht man, ob was gefunden wurde !!!
@MessageBox(Gesuchte Nummer : + Number$ +
Länge SuchString : + @str$(@Len(Number$)) +
Gefunden JA [1,2,...] / NEIN [0] : + @Str$(Tel_Gef&),INFO,262144+16)
Case Tel_Gef& : DS_Einlesen wenn gefunden, Datensatz einlesen
Else
@dbIndex(IDX_Name)
@dbGo(Top)
EndIf
@dbIndex(IDX_Name) Wieder Standart-Such-Index setzen
Return Tel_Gef&
Dabei ist mir aufgefallen, da zwar das überprüfen, ob alle Indexe vorhanden sind (Zeile 8-10) funktioniert, aber bei Rückgabe 0 (ein Index fehlt) ein neues zuweisen des zu benutzenden Index zum Programm-Abbruch führt. Ich weiss, das überprüfen kann ich auch anders machen, ist aber schon seltsam...
Mario |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 18.03.2008 ▲ |
|
|
|
|
Thomas Freier | Beim Indizieren besteht eine Begrenzung für die Länge des Index. Ich glaube es ist sind 110 Zeichen. Also z.B. 4x Feldlänge N30 = 120= zuviel zum Indizieren. Bitte in der Hilfe oder hier danach suchen oder für jeden Suchvorgang im Programm nur ein Feld indizieren. Das sind doch nur einige Programmzeilen mehr, aber weniger Probleme. |
|
|
| |
|
|
|
E.T. | @Thomas : Danke für Deine Antworten. Der Index lag über 4 (6) Felder a15 Zeichen, also 60 (90) lang. Das sollte nicht das Problem sein.
Habe nach langen überlegen jetzt doch auf @dbseek umgebaut. So kann ich mir auch die Indexe sparen. Dachte halt nur, das suchen im Index wäre schneller...
Hab zwar jetzt das Problem mit der Überprüfung nicht mehr (siehe 2 Posts weiter oben), aber interessant wäre schon zu wissen, woher der Programm-Abbruch kommt.
Mario |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 18.03.2008 ▲ |
|
|
|
|
Thomas Freier | Das von mir als mögliche Fehlerursache beim Indizieren Genannte traf ja nicht den Kern. Du erstellst ja getrennt 6 *.ndx und fragst ab, ob sie vorhanden sind. Wie die *.ndx erzeugt werden ist ja nicht ersichtlich. Ob sich da noch ein Fehler eingeschlichen hat? Ist da ein unsauberer Mix aus Alpha- und Num-Feldern? Das suchen mit Index ist schon schneller. Ein merkbarer Zeitgewinn ist erst bei großen Dateien feststellbar. |
|
|
| |
|
|
|
E.T. | |
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 19.03.2008 ▲ |
|
|
|
|
Thomas Freier | Es sieht so aus, dass alle *.dbf und *.ndx beim Programmstart geöffnet, bzw. erzeugt werden. Stößt du an die Grenze der 15 geöffneten Dateien (Hilfe, Referenz)? Da XProfan den Befehl reIndex nicht kennt, hatte ich mir es angewöhnt, die gewünschte *.ndx erst zu erzeugen, wenn sie benötigt wird und dann ist sichergestellt, dass alle Datenbankänderungen erfasst sind. In solchem Fall nur ein ndx-Name, vor Erstellung löschen, Abfrage und suchen und das eben für jedes Feld in dem gesucht werden soll. Dann ist es in einer kurzen doWhile-Schleife abgefragt, wenn Feld-Nr. verwendet werden und die Felder hintereinander liegen. Ich würde auch keine Fehlermeldung ausgeben, wenn die *.ndx nicht vorhanden ist, sondern dann automatisch von dbfind zu dbseek wechseln. |
|
|
| |
|
|
|
E.T. | Es wird nur EINE Datenbank geöffnet und verschiedene Indexe erstellt, welche dann jeweils bei der Bearbeitung zum sortieren genutzt werden (natürlich immer nur einer, dann mal wieder ein anderer). Das das suchen in einem Index über mehrere Felder nicht funzt kann erkläre ich mir damit, das im Index alle Felder in EINEM String stehen. Bin ich drauf gekommen bei der Suche in IDX_Name, welcher aus Name + Vorname erstellt ist. Dort muss ich den Suchbegriff für Name auch erst auf die (vorgegebenen) 30 Stellen auffüllen, um bis zum Vorname zu kommen. Das funktioniert aber auch wunderbar.
Was mich jetzt immer noch stutzig macht ist der Absturz nach der Kontrolle, wenn dann ein anderer Index zugewiesen wird. Passiert auch bei @dbGo... usw. Irgendwo verhaspelt sich da was, habs nur noch nicht gefunden (und XPSE sagt auch nix).
Mario |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 19.03.2008 ▲ |
|
|
|
|
Thomas Freier | @Mario: ich denke, du hast dein Programm voll im Grif und alles ausgelotet was machbar war. So wie du die *.ndx verwendest, ich habe leichte Zweifel, ob das im Sinne des Erfinders war. An dieser Stelle bitte ich @Roland: wie es mit der zulässigen Anzahl von offenen *.ndx pro *.dbf? Bei dBase III waren sieben. |
|
|
| |
|
|
|
E.T. | @Thomas: Danke für deine tröstenden Worte.
Habe jetzt die ganze Suche nach Tel-Nummern in meinem Prog auf dbSeek umgebaut. Da kann ich mir paar (viele) Indexe sparen (sind mittlerweile nach Kundenwunsch allein 6 DB-Einträge für Tel-, Fax-, Handy- Nummern geworden). Der Gedanke von Thomas mit der Anzahl der Indexe ist gut, da sich ja XProfan (meines Wissens) an den DBaseIII - Standart hält, ist es gut möglich, das da (bei meiner Nutzung der Indexe) der Hase begraben liegt
(Oh, , kurz vor Ostern sollte der Hase ja noch hoppeln, naja, bei mir sind trotzdem 2 in der Pfanne.... ).
Das ganze habe ich ja mittels Umbau gelöst, bin aber alledem gespannt, ob Roland noch was dazu hören lässt.
Mario
P.S. Heute hab ich endlich mein XProfan 10 bekommen. Da kanns ja nur besser werden. Und jetzt schmeise ich endlich meine Tastatur weg und stecke die Neue ran, welche seit 4 Wochen da liegt. Wenn dann nicht mehr abundan ein paar Anschläge fehlen, werden ggf. auch die Fehler in meinen Quelltexten weniger. Aber man soll ja auch seine Alte (T..) lieb haben.... (Diesen Beitrag wenigstens 5mal wegen fehlender Zeichen korrigiert - jetzt reichts !!) |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 20.03.2008 ▲ |
|
|
|