XPPFatal unter Citrix

[andreas]

Hallo Leute,

ich habe ein grosses Problem was auch sehr eilt.

Wenn mein Programm über Citrix-Terminalsitzung gestartet wird, kommt es oft an unterschiedlichen Stellen zu unterschiedlichen Fehlern, wonach das Programm abstürzt.
Die letzte Meldung war als Fatal-Fehler aufgetreten.

FATAL ERROR LOG
System-Error
SYS Thread-ID: 496
Module: MOM
Error Codes: EH: 4 Sub: 5(5) OS: 5 XPP: 40
Call Stack of Thread 1 (496):
@XBPCOLUMN@I@ROWMOTION(813)
(B)@XBPCOLUMN@I@CREATE(409)
MAIN(276)
Call Stack of Thread 2 (708):
Call Stack of Thread 3 (1200)

Kann mir jemand sagen, was die bedeutet?

[Martin Altmann]

Hallo Andreas,
wollen wir mal sehen, ob wir das mit Hilfe der Datei von Andreas Gehrs-Pahl aufgedröselt bekommen:
MOM: Memory Object Manager
OS: Operating System Fehler 5: Zugriff verweigert

Viele Grüße,
Martin

[Martin Altmann]

Hallo Andreas,
und? Hast Du schon was gefunden?
Versuchst Du vielleicht, eine Datei "shared" zu öffnen, die bereits exklusiv geöffnet ist?
Oder eine Datei, auf die Du anderweitig (OS?) keine Zugriffsrechte hast?

Viele Grüße,
Martin

[andreas]

Hallo Martin,

ich habe nach der langen Suche und Stress mit den Kunden den Fehler gefunden. An Citrix liegt es garnicht.

Ich habe in der Datenbank ein logisches Feld. Beim Arbeiten mit der Datenbank wurde ein Filter in folgender Form gesetzt:

Code: Alles auswählen

set filter to ! db->test

Genau diese Form des Filters hat das Programm nach ein Paar Arbeitsschritte mit der Datenbank das Programm ständig zum Absturz gebracht.
Nach dem ich die DBFNTX-Datenbank angesehen habe, habe ich festgestellt, dass das Feld kein Wert enthält, wenn es noch nie gesetzt war. Dann habe ich die Filterbediengung auf folgende verändert:

Code: Alles auswählen

set filter to db->test#.t.

Seit dem funktioniert es.
Ich verstehe aber nicht, was es für unterschied machen sollte. Es ist doch die gleiche Bediengung, nur anders formuliert.

[Martin Altmann]

Hallo Andreas,
für einen Menschen ist es die gleiche Bedingung - für einen Computer nicht!
In Deinem ersten Fall prüfst Du auf .not. .t. - also wenn das Feld ein .f. enthält - leere Felder sind dann weder .t. noch .f. sondern NIL und bereiten dabei Probleme.
Im zweiten Fall prüfst Du auf <> .t. -> sowohl NIL als auch .f. sind <> .t.

Viele Grüße,
Martin

[Wolfgang Ciriack]

Wie kann denn ein logisches Feld in einer DBF leer sein ?
Beim Einfügen eines logischen Feldes wird dieses doch immer automatisch mit .F. initialisiert ?

[andreas]

Hallo Wolfgang,

das habe ich auch gedacht und immer die bediengung so gesetzt. In diesem Fall ist es aber wohl anders. Oder erst seit 1.9.

[AUGE_OHR]

hi

Module: MOM
Error Codes: EH: 4 Sub: 5(5) OS: 5 XPP: 40

set filter to ! db->test

set filter to db->test#.t.

in dem Zusammenhang :

SET RUSHMORE ON/OFF
SET SMARTFILTER ON/OFF
SET OPTIMIZE ON/OFF

gruss by OHR
Jimmy

[brandelh]

Hi,

eine DBF hat auch unter 1.90 immer vorbelegte 'leere' Felder, solange man die NULL Unterstützung (ein Feld wurde noch nie belegt) nicht eingeschaltet hat (weiß jetzt gar nicht wie man das macht ...). Das dürfte also nicht sein, eventuell gibt es ja ein Zugriffsproblem auf die Datei, wir hatten einmal Probleme mit einem völlig überlasteten Server, die kappen im Hintergrund unbenützte Verbindungen, wenn dann ein Zugriff nötig wird, versuchen sie die Verbindung schnell wieder herzustellen, was gut geht solange Resourcen frei sind.