Datenbankeintrag wird nicht gefunden [erledigt]

[noat]

Hallo zusammen,

hat jmd. eine Idee, woran es liegen könnte, dass ein Eintrag in einer Datenbank-Datei (DBFNTX) nicht gefunden werden kann (FOUND() gibt False zurück), obwohl

• der Suchbegriff (Artikelnummer aus Zahlen ohne führende Null bestehend) die richtige Anzahl an Stellen hat (Artikelnummer + Leerzeichen) und so eine exakte Übereinstimmung besteht,

• die gesuchte Artikelnummer mehrfach in der Datenbank vorkommt,

• der richtige Index verwendet wird,

• die richtige DBE geladen ist,

• SET DELETED ON gesetzt ist.

Das Komische ist,

• dass der Aufruf mit allen möglichen anderen Artikelnummern funktioniert.

• Und in Verbindung mit anderen Datenbanken (DBF-Dateien) funktioniert auch der Aufruf mit genau dieser Artikelnummer.

• Die Funktion und Zugriff auf diese Datenbank funktioniert auch mit dieser Artikelnummer in Verbindung mit anderen Programmen (mit Xbase Parts und VIO mode), nur über die Browser-App nicht.

Mein Anwendungs-Setting: Eingabe der zu suchenden Teilenummer über CXP-Datei, Übergabe an eine Funktion (helper.dll), die die Datenbankabfrage über eine included PRG-Datei macht.

Ich habe keine Idee mehr, wie ich das noch irgendwie debuggen könnte, da ich mich ja in die FOUND()-Funktion nicht reinhängen kann.

Code: Alles auswählen

   SELECT(nSelCADDOK)
   GO TOP
   SEEK cTeileNr
   IF (FOUND() == .T.)

Falls mir jemand einen Tipp hat, woran es liegen könnte bzw. wie evtl. weiter analysieren könnte, wäre ich sehr dankbar!

Gruß
noat

[Tom]

Nun, wenn eine Reindexierung auf der fraglichen Tabelle bereits stattgefunden hat (hat sie?), wird es, wenn alles zutrifft, was Du schreibst, schwierig. Wenn man die Tabelle in einem Browse öffnet und den fraglichen Index als führend wählt und DELETED ON ist, wird der Datensatz dann angezeigt? Und auch an der richtigen Stelle, die die Sortierung durch den Index vorgeben würde?

Es kann natürlich auch ein simpler Tippfehler vorliegen, den man nicht gleich sieht.

[noat]

Hallo Tom,

eine Reindixierung hat geholfen. Allerdings ist mir das unerklärlich, weil die Verwendung der exakt gleichen Funktion von einem anderen Programm aus funktioniert hat und die Datensätze gefunden wurden und zur Anzeige gebracht werden konnten.

Danke dir!

[Tom]

Hallo, noat.

Dann war/ist es im anderen Programm nicht exakt gleich. Möglicherweise gibt es weitere Indexe ähnlicher Art, oder es wurde anders gesucht usw.

Wenn es zu einem Phänomen nur extrem vereinzelte Fälle gibt, liegt es häufiger an den Daten als am Code. Und einen nicht ganz aktuellen Index kann es bei dateibasierten Datenbanken leider immer geben.

[Jan]

Moin,

in solchen Fällen ist es manchmal ein blöder Fehler oder eine Einstellung, an die man hier nicht unbedingt denkt. Unterschiedliche SET EXACT, RUSHMORE, OPTIMIZE, COLLATION-EInstellung (hatte ich mal mit zu kämpfen vor einigen Jahren). Gesetzter Filter oder Scope. Unterschiedlicher SetLexRule. Gesetzte Relationen, die den gesuchten Satz ausblenden. Es gibt da so vieles was da rein spielen könnte.

Jan

[noat]

Leider war ich etwas zu voreinlig.
Die Reorganisation hat in dem geschilderten Fall geholfen, aber jetzt ist das Problem wieder aufgetreten, obwohl der Index letzte Nacht erst neu erstellt wurde.

Die Artikelnummer lautet: "F_23_A_0101" und "F_23_A_0204". Ist jetzt auch nix Kritisches mit Sonderzeichen, Umlauten, etc.

Ich habe mal <% SET CHARSET TO OEM %> gesetzt, mal <% SET CHARSET TO ANSI %>, dann ganz weggelassen. Leider ohne Änderung.
Auch wenn ich die Artikelnummer hart codiere, kann diese nicht gefunden werden.

Wenn ich eine andere DBF-Datei nehme und nach der Artikelnummer suche, findet das Programm den Eintrag in der Datenbank genauso wenig.

Mir gehen allmählich die Ideen aus, was ich tun könnte oder wie ich weiter analysieren könnte, um die Ursache zu identifizieren.

@ Jan:
Was ist "RUSHMORE"? Finde zu diesem Begriff nichts in der Hilfe.

[Tom]

Das kann bei diesem Inhalt mit Zeichensätzen und Kollationstabellen usw. eigentlich nichts zu tun haben. RUSHMORE (SET RUSHMORE ist in der Hilfe dokumentiert) ist eine (anfangs nicht sehr verlässliche, inzwischen gut funktionierende) Technologie, die es erlauben soll, Daten in indexierten Tabellen ohne Indexsuche schneller zu finden. Außerdem gibt es noch den legendären Schalter SET SMARTFILTER, der auch eine Zeitlang problematisch war, jetzt aber auch gut funktioniert. Hier merkt sich die Engine einfach nach und nach alle Datensätze, auf die der Filter zutrifft, so dass die Bedingung nicht immer wieder geprüft werden muss. Auch das kann mit Deinem Problem nichts zu tun haben.

Ich wiederhole meine Empfehlung. Mach die Tabelle zusammen mit dem fraglichen Index (also als führendem Index) auf und zeig die wichtigsten Felder in einem Browse. Und schau Dir an, ob die Einsätze mit den fraglichen Artikelnummern überhaupt und an der richtigen Stelle vorhanden sind.
Vermutlich macht Dir irgendeine Funktionalität immer wieder die Indexe kaputt, möglicherweise, weil Du irgendwo, wo eine Aktualisierung der Daten stattfindet, vergessen hast, die Indexe mit zu öffnen. Eine abermalige Reindexierung wird also vermutlich auch diese Datensätze wieder ans Tageslicht bringen. Du hast da ein hausgemachtes Problem, das nichts mit Inhalten zu tun hat, sondern mit dem Umgang mit ihnen.

[azzo]

Ich hatte manchmal Probleme mit Copy & Paste, wenn ich z. B. E-Mail-Adressen in die Kundendatei übernehme. Hier wird dann oft ein CR LF mitkopiert.
Vielleicht kannst du die Artikelnummer händisch neu eingeben.

[noat]

Habe "SET COLLATION TO GERMAN" gesetzt. Scheint damit jetzt zu funktionieren.

Dankeschön für die Unterstützung und die Anregungen!