Inoffizielles deutsches Xbase-Forum

Kannst Du denn die besagte Tabelle inklusive Index und Schlüssel, der nicht gefunden wird, mir mal zumailen?
Vielleicht finde ich ja dann etwas .

Uli

Manfred hat geschrieben:Mit 1.82.294 compiliert und es klappt. Das muß ich jetzt nicht verstehen.

2.1 Wenn Sie eine ältere Version von Xbase++ oder anderen
Alaska-Produkten haben...

a) Compilieren Sie alles neu!

b) Neuerzeugen der CDX/NTX-Dateien

Die CDX/NTX-Dateien müssen neu erzeugt werden. Andernfalls
kann es zu einem fehlerhaften Index oder zu Programm-
abstürzen kommen.

oder der Debugger zeigt was an was nicht "wahr" ist ...

Hallo Manfred,

ich wette (von mir aus auch einen 5er) dass es daran liegt, dass entweder nicht der komplette Code unter 1.9 kompiliert wurde, oder aber beim ausführen der unter 1.9 kompilierten Version immer noch Dateien (dlls) gezogen werden, die aus der Vorversion stammen.
Ich schwüre, dass wir denselben Fehler hatten, und zwar direkt nach der Umstellung von 1.82 auf 1.9 (oder von 1.9 auf 1.9 SL1). Ich kann mich jetzt leider nicht mehr genau daran erinnern was genau die Ursache war (ist ja auch schon ein paar Tage her) aber mein Langzeitgedächtnis gaukelt mir irgendetwas von falschen dll Versionen vor.

(ACE32.DLL, AXCWS32.DLL, ADAC20B.DLL, ADAC20C.DLL, ADSDBE.DLL, ASRDBC10.DLL, CDXDBE.DLL, DBFDBE.DLL, DELDBE.DLL, etc.)

Hallo Manfred

Wie sieht dein indexschlüssel aus? Verwendest du darin Funktionen?

Gruss Carlo

Hi Carlo,

nein, es sind keine Funktionen drin.

UliTs hat geschrieben:Kannst Du denn die besagte Tabelle inklusive Index und Schlüssel, der nicht gefunden wird, mir mal zumailen?
Vielleicht finde ich ja dann etwas .
Uli

Hallo Manfred,
wenn Du das Problem trotz der Hinweise von Magic noch nicht gefunden hast, wiederhole ich gern mein Angebot .

Uli

Hi Uli,

es hat seinen Grund, warum ich darauf nicht reagiere. Datenschutz ist da so ein Zauberwort.

Manfred hat geschrieben:Hi Uli,
es hat seinen Grund, warum ich darauf nicht reagiere. Datenschutz ist da so ein Zauberwort.

Hallo Manfred,

tut mir leid, aber mit Datenschutz hat dies nichts zu tun!

Uli

Klar - das ist der Grund, warum er Dir die Sachen nicht mailen darf.

Viele Grüße,
Martin

Martin Altmann hat geschrieben:Klar - das ist der Grund, warum er Dir die Sachen nicht mailen darf.

Viele Grüße,
Martin

Das ist kein Grund, nicht zu reagieren!

Da stimme ich Dir zu.

Jetzt bin ich überrascht, der Fall war sonnenklar. Und selbst meine Antwort hat wieder unsinnige Diskussionen hervorgerufen. Ich weiß nicht ob ihr alle nur Kundendaten einfach mal so durch die Weltgeschichte schickt. Würde mich aber dann doch jetzt verdammt stutzig machen. Die Folgen, die es nach sich ziehen könnte wären doch unüberschaubar. Aber jeder so wie er meint.

Manfred, was soll denn das?

Natürlich ist es selbstverständlich, dass man Kundendaten -wenn überhaupt- nur dann weitergibt, wenn der Kunde damit einverstanden ist!
Es ging mir nur um das von Dir ausgesprochene absichtliche "ignorieren"!
Martin hat ja nett reagiert und meine Laune dadurch wieder in's Lot gebracht .

Uli

@Magic,

die Idee mit den DLL wäre sicherlich interessant, aber auf meinem System gab es die noch nie. Deshalb sollte auch ausgeschlossen werden können, das eine Vertauschung vorliegt. Sollte es doch so sein, dann müßten die anderen Programm auch Mucken ähnlicher Art mache. Das tun sie aber nicht.

Aber ich habe jetzt noch weitere DbSeeK() gefunden, die genau das gleiche Problem haben. Jetzt werde ich mal vor jedes Dbseek() ein altd() setzen und schauen, was da für Ergebnisse erzeugt werden.

So meldet sich der "Österreicher" wieder einmal.
Manfred ich erschlage dich mal mit einem Haufen Fragen
Manfred hast du in besagtem Record Umlaute oder sonstige Sonderzeichen darin?
Zeigt DbSeek auch .F., wenn du einen beliebig anderen Satz anspringst?
Ist die Datentabelle gross, hast du ev. mehr als 32'000 Sätze?
Was zeigt Seek beim Finden eines der ersten Datenrecords?

Hi Herbert,

es ist im Moment schier unglaublich, was sich da auftut. Mal klappt es, mal nicht. Der Satz wird auf jeden Fall gefunden (ich sehe den Satz im Debugger), aber Dbseek() liefert .F. (auch im Xppdbg). Das Feld beinhaltet ein Datum (Textfeld im Format YYYYMMTT) und so wird auch gesucht (über DToS). Wenn ein Datum in der Vergangenheit gesucht wird, dann wird .F. zurückgegeben, Gegenwart? aber zumindest Zukunft klappt. Ich verstehe immer weniger. Ich habe jetzt erstmal an den Stellen eine Krücke eingebaut, damit der User arbeiten kann. Es sind nur schlappe 2700 Sätze in der DBF.

Ha,

jetzt habe ich was ganz tolles gesehen. Ich habe gerade einen Menuzweig gefunden, der die DBF browsed. Dort kann man sehen, wie der geforderte Satz angesprungen wird, aber trotzdem ein .F. zurückgeliefert wird.

Manfred hat geschrieben:Hi Herbert,
Mal klappt es, mal nicht.

Was meinst du damit? Beim selben Aufruf mal so, mal so?

Autsch,

nein, habe da falsch formuliert. Es klappt in dem Index zu suchen in dem einem Modul und nicht in einem anderen Modul. Aber das werde ich noch genauer untersuchen, ob die Fälle identisch sind. Der Aufruf ist aber jedesmal der gleiche.

Hi Manfred,

ich schlage noch folgendes als Fehlerursache vor:

- der Index besteht nicht nur aus dem Datumsfeld sondern ist zusammengesetzt aus mehreren Feldern(?), dann könnte die ANSI Sortierung etwas mit dem falschen Ergebnis zu tun haben.

nightcrawler hat geschrieben:Die ANSI-Sortierung GERMAN sieht ein Leerzeichen nach dem Bindestrich vor...

Das hat bei mir zu den merkwürdigsten Ergebnissen geführt. Anfangs nicht immer reproduzierbar und vor allem unlogisch.

- Der Index ist an sich kaputt und muss evtl. noch mal neu aufgebaut werden.

- Oder ganz simpel, vor dem DbSeek() ist noch ein DbSetScope(…) aktiv, der den Satz schon mal „ausfiltert“ (hatte ich gerade unter 1.9 SL1). Dann sollte ein DbClearScope() direkt vor dem DbSeek() auf jeden Fall das Problem lösen (vielleicht mal einfach ausprobieren).

- Vielleicht ist aber auch noch ein DbSetFilter() aktiv?

Hi Magic,

nichts von dem trifft zu. Alles schon nachgesehen und getestet.

Hallo Manfred,

Du erinnerst Dich, das ich Dich mal wegen eines ähnlichen Fehlers bei mir angerufen hatte? Du warst nur gerade auf dem Sprung, deswegen hattest Du das bei mir nicht gesehen.

Bei mir hat der plötzlich an einer Stelle, die immer gelaufen ist, einen Fehler beim DbSeek() gemacht. Der hat immer die falsche Rückgabe gegeben, immer ein .F. Ich konnte machen was ich wollte, der ist die Schleife nie reingegangen.

Am nächsten Tag: Rechner neu gestartet, alle .obj gelöscht, Projekt neu aufgebaut - es lief wieder! Als wenn sich da im Arbeitsspeicher oder sonstwo irgendwas verknotet hatte.

Nun läuft das Problem bei Dir schon etwas länger. Rechner neu starten wird also wohl schon mehrfach passiert sein. Und ich weiß daß Du mit jedem Compilerlauf immer alle .obj vorher löschst. Das kann es also bei Dir nicht sein.

Beine Vorschläge:
1) Benutze mal im DbSeek() alle drei Parameter. Ich tippe mal nicht auf einen Fehler im softseek, der wäre ja genau andersherum (found() gibt .T. zurück, obwohl der falsch steht). Aber das mal eben schnell zu probieren ist ja kein Aufwand.
2) Kopiere mal alle Datensätze in eine neu angelegte dbf. Nicht mit COPY TO oder SORT TO, sondern manuell. Nur um zu checken, ob im Dateiheader oder sonstwo eventuell was durcheinander geraten ist.

Jan

Wird bei Softseek nicht auch ein .F. zurückgeliefert, wenn es den Wert nicht gibt, aber der nächste genommen wird? zumindest bekommt Found() ein .F.

Hallo, Manfred -


hier mal eine Zusammenstellung, was die Dokumentation zu dem Thema hergibt:


http://wiki.xbaseentwickler.de/index.ph ... f#Softseek

Hallo Manfred - und Interessierte

das ist alles schon lange her - aber des Rätsels Lösung würde mich schon noch interessieren -
- weil ich konkret auch an einem Problem mit SEEK, resp. DbSeek herumkaue, das mir viele Rätsel aufgibt ...

bei mir läuft ein SEEK in Xbase1.9-SL1 nicht mehr wie in 1.9 ohne SL

P.S. hab auch sonst im Forum nach SEEK gesucht - und allerlei durchgelesen