DbSeek() gibt im ADS einen Laufzeitfehler

[Jan]

Ich habe einen reproduzierbaren Fehler: Ich suche per DbSeek einen Wert. Vollständig sieht die Zeile so aus:

Code: Alles auswählen

IF wagrups->(DbSeek(aWarengruppe[i][1], , "wagrwagr"))

Die Fehlermeldung lautet dann:

oError:args :
-> VALTYPE: C VALUE:AK20
-> VALTYPE: U VALUE:NIL
-> VALTYPE: C VALUE:WAGRWAGR
oError:canDefault : .T.
oError:canRetry : .F.
oError:canSubstitute: .F.
oError:cargo : NIL
oError:description : Parameter hat falschen Typ
oError:filename :
oError:genCode : 2
oError:operation : DbSeek
oError:osCode : 0
oError:severity : 2
oError:subCode : 3
oError:subSystem : BASE
oError:thread : 1
oError:tries : 0

Was immer "Parameter hat falschen Typ" zu bedeuten hat ... Und welcher der Parameter damit gemeint ist ...

Ich habe dann mal das ganze runtergebrochen auf eine Minimalversion. Also nur den ersten Parameter, und den auch fest kodiert auf einen vorhandenen, korrekten Suchbegriff ("AK20"). Die Fehlermeldung bleibt die Gleiche.

Interessant dabei ist: Wenn ich in VX die Suche in das Command Window eingebe, dann gibt das eine Rückgabe von .F. Also "Nicht gefunden". Eine Abfrage auf den RecNo() gibt mir aber den korrekten Datensatz.

Ebenfalls ist der Fehler reproduzierbar auf zwei bestimmte Kunden in dem System. Bei einem dritten Kunden klappt es dagegen reproduzierbar richtig. Die Abfrage ist also grundsätzlich erstmal nicht falsch.

Wenn ich exakt die gleiche dbf ohne den ADS anspreche läuft alles ganz sauber. Wobei die Fehlermeldung ja auch nicht von der ADSDBE kommt, sondern aus dem ganz normalen Standard-System.
Ich bin irritiert ...

Jan

[Tom]

Hallo, Jan.

Die ADS(DBE) ist weniger fehlertolerant, wenn es um Datentypen bei der Indexsuche geht. Mit DBFNTX/FOXCDX kannst Du nach einem alphanumerischen Begriff auf einem numerischen Index suchen, ohne einen Laufzeitfehler zu erhalten, aber mit der ADSDBE kracht das. Hol Dir einfach mal Informationen darüber in Dein Log,

- welchen Datentypen der Suchbegriff hat
- welcher Index gewählt ist und führend ist
- welchen Indexausdruck es darin gibt

Du wirst möglicherweise feststellen, dass etwas davon nicht ganz richtig ist.

Ähnliches gilt übrigens nach meinem Dafürhalten auch für Indexkorruptionen. Die ADS(DBE) reagiert da sensibler - richtigerweise, wie ich finde.

[Jan]

Hallo Tom,

die Gedanken hatte ich auch alle schon. Ich habe also den führenden Index kontrolliert - es ist der Richtige (und einzige auf diese dbf). Ich habe auch den Index komplett neu aufgebaut. Der Index ist übrigens auf ein C4-Feld, das passt also auch mit dem Suchbegriff "AK20" überein.

Jan

[brandelh]

Code: Alles auswählen

DbSeek( <IndexKeyValue>, ; // das ist bei dir C
       [<lSoftSeek>]   , ; // das darf NIL sein ... 
       [<nIndex>|<cTagName>],; // stimmt der TAG-NAME mit "wagrwagr" überein ?
       [<lLast>] ) --> lFound

Der Parameter kann in der Funktion stehen, dann wäre hier nur TAG-NAME mit "wagrwagr" zu prüfen oder aber - zumindest bei Objekten -
kann die Rückgabe an den aufrufenden Parameter falsch sein ... gibt es wagrups-> als ALIAS ausgeschrieben ?

[Jan]

Hallo Hubert,

wie ich oben schrieb - selbst wenn ich das komplett runterbreche auf nur den ersten Parameter, bleibt der Fehler vorhanden. Der Typenfehler kommt aus dem Suchbegriff.

Abgesehen davon - ja, wagrups ist ein gültiger Alias, wagrwagr ist ein gültiger Tag in der CDX. Und das indizierte Feld steht pur drin, kein Upper() oder gar eine UDF.
Wenn das alles nicht so wäre würde es ja auch bei besagtem Kunden ebenfalls nicht funktionieren. Aber bei einem von drei getesteten klappt es ja.

Jan

[Jan]

Ich habe heute mal die betreffende dbf komplett neu eingespielt, und natürlich auch den Index neu aufgebaut. Der Fehler ist geblieben.

Jan

[Jan]

Nachdem ich heute mal wieder viel zu viel Zeit mit diesem Problem verbracht habe, habe ich folgendes festgestellt: Ein DbSeek(cSuchbegriff), ein DbGoTop(), und ein OrdSetFocus(cTageName) ergeben grundsätzlich den Laufzeitfehler, das der Parameter einen falschen Typen habe.

Ich habe im Debugger ein wenig "rumgespielt", und dabei folgendes herausgefunden: Ein Alias(), ein OrdKey() und ein OrdSetFocus() geben grundsätzlich einen Leerstring zurück!

Wenn ich im Debugger durchgehe, und im CommandWindow() ein OrdSetFocus(cTageName) eingebe, dann bekomme ich im, CommandOutput de bekannte Meldung, daß der Parameter einen falschen Typen habe. Was aber natürlich keinen Programmabsturz durch einen Laufzeitfehler verursacht. Und wenn ich dann danach ein Alias(), ein OrdKey() und ein OrdSetFocus() abschicke, dann bekomme ich auch die korrekte Rückmeldung! Auch ein DbSeek(cSuchbegriff), ein DbGoTop(), und ein OrdSetFocus(cTageName) geben dann genau das Ergebnis, das ich erwarte.

Nur um das noch einmal klar zu machen: Der Code läuft unter FOXCDX absolut sauber durch. Nur wenn ich den auf den ADS setze, dann kommt die beschriebene Problematik.

Hat einer von Euch eine Idee, was da für ein Probem hinter stehen könnte?

Jan

[Tom]

Mmh. Verwendest Du ADS 11 mit den 11er-Clients? Empfohlen ist die Verwendung der 10er-Clients mit der ADS 11. Vielleicht hat's was damit zu tun. Betroffen/gemeint ist die ACE32.DLL.

[Jan]

Hallo Tom,

der ADS ist 11.10.0.22. nachdem ich heute mit Friethelm als ADS-Supporter telefoniert habe, habe ich mir den 10.0-Client heruntergeladen, und die Runtimes in das Programmverzeichnis kopiert. Das gab keine Änderung.

Als Nachsatz zu meinem vorigen Beitrag: Ich habe jetzt eine Schleife eingebaut vor den DbSeek():

Code: Alles auswählen

bError := ErrorBlock({|oErr| BREAK(oErr)})
BEGIN SEQUENCE
OrdSetFocus("wagrwagr")
ENDSEQUENCE
ErrorBlock(bError)

Das mach zwar überhaupt keinen Sinn, weil ich den Fokus ansich an dieser Stelle nicht zu setzen brauche. Aber die Tour mit dem Debugger hat ja gezeigt, wenn ich den Fokus manuell setze, und dabei den entstehenden Laufzeitfehler abfange, dann klappt hinterher alles. Das ist natürlich nicht wirklich die Lösung. Ich doktere ja nur an dem Symptomen rum, der eigentliche Fehler ist damit nicht behoben. Aber jetzt kann ich erstmal alles andere durchtesten, bzw. testen lassen. Damit ich überhaupt mal irgendwie damit voran komme.

Interessant ist auch, das ich nach diesem Kunstgriff ein wenig in anderen Funktionen getestet habe. Nirgends ein Fehler! Nur an dieser einen Stelle, mit dieser einen dbf, da klappt es nicht. Andere Stellen, wo diese dbf ebenfalls verwendet wird, gibt es keinerlei Komplikationen. Muß ich im Moment nicht wirklich verstehen ...

Jan

[UliTs]

Hallo Jan,

Du hast ja auch Erfahrung mit dem ARC (Data Architekten).
Nach meiner Erinnerung hast Du ein DataDictionary über Deine Tabellen gebildet. Kannst Du die besagte Tabelle im DataDictionary öffnen? Wenn Ja, kannst Du den Index auswählen? Kannst Du mit dem Browser des ARC in der Tabelle und ausgewähltem Index "browsen"?

Ich hätte noch als Idee, dass vielleicht in einem Datensatz im Indexfeld ein ungültiger Wert steht...

Uli

[Jan]

Hallo Uli,

im ARC scheint alles korrekt zu laufen. Index ist da, sortiert auch richtig.

Jan

[UliTs]

Hallo Jan,

wenn Du im ARC im "Search"-Feld den Wert "AK20" eingibst, wird dann der Wert auch korrekt gefunden?

Dann hätte ich noch die Idee, wenn Du im ARC als Test mal in allen Datensätzen den Wert "AK20" eingibst. Klappt dann der Zugriff über das xBase-Programm?
Wenn das auch nicht funktioniert, liegt es vermutlich nicht an einem falschen Wert.

Noch eine Idee: erweitere mal das Feld um 1 Zeichen auf 5 Zeichen. Klappt es dann?

Uli

[UliTs]

Und? Wie sieht es aus?
Uli

[Jan]

Moin Uli,

nicht drängeln Ich bin heute erst wieder beim Kunden, und werd dann mal testen und nachschauen.

Jan

[UliTs]

Wenn erlaubt, nimm am Besten eine Kopie vom DataDictionary zum Testen mit nach Haus .

[UliTs]

Hat sich inzwischen etwas ergeben?

Uli