"Ungültiger Datentyp für Feld/Indexschlüssel"

[Jan]

Ich habe ab und an, sehr sporadisch, diesen Fehler:

Code: Alles auswählen

FEHLERPROTOKOLL von "P:\06 NG_Prog\logi84.exe" Datum: 13.07.2012 14:50:41

Xbase++ Version     : Xbase++ (R) Version 1.90.355
Betriebssystem      : Windows Vista 06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args         :
          -> VALTYPE: N VALUE: 0
oError:canDefault   : N
oError:canRetry     : N
oError:canSubstitute: J
oError:cargo        : NIL
oError:description  : Ungltiger Datentyp fr Feld/Indexschlssel
oError:filename     : 
oError:genCode      :         62
oError:operation    : <ID>:=<0>
oError:osCode       :          0
oError:severity     :          2
oError:subCode      :       8028
oError:subSystem    : BASE
oError:thread       :          1
oError:tries        :          0

Also: Es soll der Wert 0 in das Feld ID geschrieben werden. ID ist N8.0. Da 0 ja nun eindeutig numerisch ist - warum meckert der?

An anderer Stelle hatte ich das schon. Da habe ich einfach gefrustet ein Konstrukt Val(Var2Char(nWert)) zugewiesen. Sinn der Sache kann das ja aber nicht sein.

Jan

[Rolf Ramacher]

Hi Jan

ist ID Local definiert ? oder wird vielleicht an einer anderen Stelle anders als numeric zugewiesen ??

[Jan]

Ähm, Rolf,

wie ich schon schrieb: ID ist ein Feld und hat N8.0. Da geht nicht "anders überschrieben"

Jan

[georg]

Hallo, Jan -


trotzdem würde ein kleiner Code-Ausschnitt um die Fehlermeldung herum schon helfen, sowie die Definition des Index/der Indexe, falls mehrere.


Gruss,

Georg

[Jan]

Hallo Georg,

ich muß gestehen daß ich den Sinn nicht ganz erkennen kann. Ich weise einem numerischen Feld einen numerischen Wert zu. Das Errorlog sagt auch ganz eindeutig, daß der Wert numerisch ist. Es klappt auch fast immer. Nur manchmal, sporadisch, knallt es mit der zitierten Fehlermeldung.

Jan

[georg]

Hallo, Jan -


gerade darum frage ich ja. Es hat mir mehr als einmal geholfen, einen Kollegen, der von Programmierung keine Ahnung hat, herbeizurufen und ihm zu erklären, was mein Programm an so einer Stelle macht. Dabei geht mir dann meistens ein Licht auf, was schief läuft. Und ich dachte, vielleicht hilft Dir so ein Vorgehen auch.


Gruss,

Georg

[Koverhage]

Hallo Jan,

nach meiner Erfahrung bezieht such die Fehlermeldung nicht auf das Feld sondern auf den Indexschlüssel
und ist nach einer Neuerstellung der Indexdatei behoben. Sicherlich kann die Neuerstellung auch nicht Sinn
der Sache sein, aber dort solltest Du ansetzen.

[UliTs]

..ich muß gestehen daß ich den Sinn nicht ganz erkennen kann..

Kann es sein, dass Du zur Zeit ganz "sinnfrei" bist
Aber im Ernst: auch wenn man selbst den Sinn manchmal nicht sieht, kann man trotzdem der Bitte des Fragenden nachkommen und 2 Zeilen wie

Code: Alles auswählen

N := 5
REPLACE Nummer WITH N

veröffentlichen ...
--
Ich vermute auch, dass der Index defekt ist...

Uli

[Jan]

Uli,

ich will ja nicht abstreiten, das ich ab und an mal ein wenig neben der Spur bin. Und um Eure Fragen zu beantowrten:

1) Auf dem Feld ist garkein Index.
2) Wenn ich

Code: Alles auswählen

alias->feld := nVariable

schreibe, dann knallt das ganz selten mal. Wenn das Programm dann abgestürzt ist, man das neu startet, dann klappt es wieder. Ohne zu reindizieren. Ich habe jetzt schon einen Workarround eingebaut, mache an den betreffenden Stellen ein

Code: Alles auswählen

alias->feld := Val(Var2Char(nVariable))

. Das klappt immer! Also ob der manchmal der Meinung ist, nVariable sei garnicht wirklich numerisch. Obwohl das Errorlog das ja ganz eindeutig aufzeigt. Und wenn ich den durch Val() auf numerisch zwinge, dann klappt alles.

Jan

[Martin Altmann]

Moin Jan,

Also ob der manchmal der Meinung ist, nVariable sei garnicht wirklich numerisch.

bzw. die Datenbank ist bereits geschlossen!! Schon mal in die Richtung geprüft?

Viele Grüße,
Martin

[Koverhage]

Jan,

das Problem ist, das die Zeile nicht unbedingt die Ursache sein muss.
Diese Meldung kommt bei mir nur dann, wenn irgendwas mit dem Index nicht in Ordnung
ist und immer bei einem Feld was nichts mit dem Index zu tun hat.

[Jan]

Hallo Martin,

hmmm, das muß ich mal checken. Die betreffenden Felder sind immer die ersten in der Reihe der zu füllenden, da wäre das dann logisch das immer die Zeilen sich melden würden. Allerdings wird in der ganzen Anwendung immer alles am Anfang geöffnet und erst beim Beenden wieder geschlossen. Sollte also eher nicht passen.

Moin Klaus,

ich hasse sowas! Wenn die Fehlermeldungen nicht darauf weisen, wo der Fehler passiert! Aber ich glaube nicht, daß das hier der Fall ist. Denn wie gesagt, wenn ich den auf Val() zwinge, dann tritt der Fehler an der Stelle nie wieder auf. Aber ich durchforste mal den Code, ob die Stellen, wo der Fehler auftritt, rundrum um die "angebliche" Fehlerzeile andere Ähnlichkeiten aufweisen.

Jan

[UliTs]

...Die betreffenden Felder sind immer die ersten in der Reihe der zu füllenden, da wäre das dann logisch das immer die Zeilen sich melden würden.

Als Test könntest Du mal die Reihenfolge vertauschen, z.B. ein anderes numerisches Feld an erster Stelle und auch mal ein anderes nichtnumerisches Feld an erster Stelle.
Tritt der Fehler dann immer noch an der ersten Stelle auf?
Uli

[Jan]

So, gerade hatte der Anwender den Fehler wieder. An einer Stelle, wo ich noch nicht die Feldreihenfolge geändert hatte.

Hier gibt es eine Besonderheit: Das Feld wird nicht mit dem Variableninhalt gefüllt, sondern mit dem Inhalt eines Feldes einer zweiten dbf. Aber wieder die erste Zuweisungszeile, wieder numerische Felder.

In diese Zeile konnte der nur reingehen, wenn in einer IF-Abfrage Feldwerte der auszulesenden dbf passen. Die muß also offen sein. Die andere, deren Feld gefüllt werden soll, bekommt vorher ein Append, ohne Fehlermeldung.

Jan

[Herbert]

Hast du schon geprüft, ob "nVariable" in diesem Fall wirklich numerischen Inhalt aufweist oder halt doch einen anderen Datentyp besitzt? (Ok scheint nicht mehr der Fall zu sein)

Ganz anderer Gedanke: ich hatte mal das Problem, dass ein Feld bei mir einen dummen Namen hatte, weiss aber nicht mehr welchen und ähnliche Fehler brachte.
Kannst du zum Testen das Feld ev. umbenennen oder ein neues mit anderer eindeutigerer Bezeichnung einfügen und auf dieses prüfen?

"ID" für einen Feldnamen ist so oder so nicht schlau. Wenn du in 4 Datenbanken ein Feld namens "ID" führst, hilft das schon nur der Lesbarkeit deines Codes gar nicht. Wenn die .dbf z.B. "Kunden.dbf" heisst, so nenn das Ding z.B. "KundenID".

[Scarmo]

Hallo Jan

Mein Gedanke war ebenfalls, ob das Feld "ID" wirklich DIESES Feld ist, welches Du ansprechen möchtest (z.B. ALIAS vergessen etc.). Oder hast Du allenfalls ein Feld "ID", welches eben kein numerisches, sondern z.B. ein CHAR-Feld ist? Ich persönlich glaube nicht, dass es irgendwas mit dem Index zu tun hat...

Gruss
Marco

[Jan]

Hallo Herbert und Marco,

seit einem XUG-Treffen vor einigen Jahren in Osnabrück spreche ich Datenbankfelder grundsätzlich nur mit Alias an. Das kann also nicht das Problem sein.

Und Feldnamen ändern ist schwierig. Da das eine bestehende Anwendung ist, wo tierisch viel Code hinter hängt, und ich da wenig Einfluß drauf habe. Ich hatte hier mal ein Feld, das hieß wie eine Xbase++-Anweisung, das war schon etwas seltsam, aber es funktionierte merkwürdigerweise. Das Feld haben wir aber dann, wenn ich mich richtig erinnere, umbenannt. Sicher ist sicher.

Ich habe vorhin an allen relevanten Stellen mal die Feldreihenfolge geändert. Jetzt muß die Zeit zeigen, ob das irgendwas bewirkt ...

Jan

[AUGE_OHR]

hi,

Klaus hat 2x drauf hingewiesen das es wohl weniger mit dem "Feld" als mit dem "Index" was zu tun hat.
siehe doch nach dem Absturz in der DBF nach ob da schon was steht ...

ich gehe davon aus das "ID" als IndexKey() in einem "mitgeführten"*** Index vorhanden ist.
*** immer alle betreffenden *.NTX öffnen !

du kannst es ja mit diesem Workaround versuchen

Code: Alles auswählen

nOldOrder := IndexOrd() 
DbSetOrder(0) 
IF RLOCK()
   REPLACE ...
   UNLOCK
ENDIF
DbSetOrder(nOldOrder)

ob sich was "ändert" im Verhalten.

p.s. alles was nicht Cl*pper ist würde ich erst mal auf OFF stellen und später "Optimierung" betreiben

[brandelh]

Wenn es nur sporadisch auftritt, kann es kein Problem mit dem Feldnamen sein.
Eigentlich auch nicht mit der Syntax, sonst müsste immer ein Fehler kommen.
Wäre die Datei nicht offen käme etwas wie "ungültiger Alias ..."
Wenn eine Zeile wie

Code: Alles auswählen

replace Alias->nFeld := 0

einen ungültigen Typ ergibt, fehlen mir die Worte ... (das darf einfach nicht passieren ...)
eventuell kann man mit 0.0 etwas nachhelfen.
Wenn bei der Zuweisung einer Variablen sowas passiert, stellt sich mir die Frage nach PRIVATE oder LOCAL ...
Bei PRIVATE könnten es Nebenwirkungen von Funktionsaufrufen sein ... alles sehr seltsam.
Wenn man es auf eine Stelle eingrenzen kann, würde ich versuchen mit

Code: Alles auswählen

if "N" # valtype(...)

den Fehler abzufangen eigentlich unnötig, aber wenn man dadurch Ruhe hat

[Martin Altmann]

Moin,

Wäre die Datei nicht offen käme etwas wie "ungültiger Alias ..."

darauf kann man sich leider nicht verlassen

Jan,
wie heißt denn der Alias der betreffenden Datei? Gibt es vielleicht eine Variable, die den selben Namen hat?

Viele Grüße,
Martin

[Jan]

Jimmy,

wie oben bereits auf den entsprechenden Hinweis geantwortet: Nein, da ist eindeutig kein Index drauf.

Jan

[Jan]

Martin,

nein, der Alias ist eindeutig. Zum Glück.

Jan

[Koverhage]

Jan,

es hat damit nichts zu tun, ob auf dem betreffenden Feld ein Index drauf ist!
Klar wenn das Programm abstürzt und es wieder neu gestartet wird funktioniert das, weil der Satz bzw. Index geschrieben wurde.
Es muss ja auch nicht sein das der Fehler bei Dir liegt.
Wie gesagt ich habe die Meldung auch ab und an mal und hat nie was mit dem Feld zu tun, sondern mit dem Index.

[UliTs]

Wie gesagt ich habe die Meldung auch ab und an mal und hat nie was mit dem Feld zu tun, sondern mit dem Index.

Du meinst "..., sondern mit einem zur Tabelle gehörenden Index.", oder?
Meinst Du, dass dann der Index kaputt ist?

Uli

[Koverhage]

Es ist zu vermuten das der Index defekt ist. Mit Index meinte ich den, der zu schreibenden Datei.
Habe gerade nochmals nachgeschaut. Typischerweise erscheint der Fehler bei dem ersten Feld (seltener beim letzten), nicht der Datei, sondern
bei dem welches zuerst replaced werden soll.
Dbf
KZ_ID N 9, 0
NAME C 30
STATUS L 1
..

Dbf Datei ist indiziert nach KZID

Wenn jetzt der Append durchgeführt wird, z.B.
alias->STATUS := .t.
alias->NAME := "FEDDER"
alias->KZ_ID

Hier würde er den Fehler bei STATUS bringen.