Error NTX Index öffnen OrdListAdd Fehler 8999

[Daniel]

Hallo liebe Kollegen

Beim Kunden tritt ab +zu ein Fehler beim Öffnen der Indexdatei (NTX) auf.
Nun frage ich ja beim Öffnen der DBF mittels einer FUNC auf NetErr() ab. Das geht ja leider bei SET INDEX, resp. OrdListAdd() nicht.
Zwar bietet die Standard-Errorsys die Option 'Retry'/"Wiederholen" an, doch wenn der Anwender die nicht nutzt, fliegt er raus.

Aus dem Errorlog:
- args
-> VALTYPE C VALUE: Index.NTX
- canRetry : J
- cargo : NIL
- description: Datei kann nicht geöffnet werden
- gencode : 71
- operation : OrdListAdd
- osCode : 0
- severity : 2
- subcode : 8999

Hat da jemand eine Lösung oder einen Tipp?
Kann man das irgendwie gescheit abfangen ?

[Tom]

Datenbankverzeichnis im Virenscanner als Ausnahme deklarieren. Und/oder: In der Errorsys "Datei kann nicht geöffnet werden" bei tatsächlich vorhandenen (!) Indexdateien abfangen, ein paar Millisekunden warten und dann zwei-, dreimal Öffnungsversuch wiederholen.

[Daniel]

Danke, Tom

Ich erweitere also das Errorsys.prg
Da habe ich noch eine Frage:

In der STATIC FUNCTION StandardEH() gibt es einen CASE XPP_ERR_OPEN ...
Dem füge ich einen weiteren an:

Code: Alles auswählen

CASE oError:genCode  ==  XPP_ERR_OPEN   .AND.   ;
     oError:operation == "OrdListAdd"
         Sleep( 5)           

- und dann? Mit RETURN .T. kann ich den letzten Programmschritt wiederholen, richtig?
Aber dann riskiere ich eine Endlosschlaufe, da ich die Wiederholungen nicht zählen kann.

Wollte ich die 'operation' innerhalb der Fehlerbehandlung wiederholen, müsste ich darauf vertrauen, dass ich in 'args' den richtigen Indexdateinamen erhalte. Sieht mir ein wenig nach Blindflug aus ...

[Daniel]

Gut, ich meine, 'oError:args' kann man schon auswerten, wie das unten in der STATIC PROC Errorlog() gemacht wird. Es ist ja ein Array.

Hab einfach ein bisschen Respekt vor dem Ding, ich hab schon mal einen "Fatal Error" mit "Error within the errorlog" (oder so ähnlich) produziert ...

[brandelh]

Und warum kannst du das nicht zählen ?

ICH nutze dafür eine Static Variable, etwa so ...

Code: Alles auswählen

STATIC FUNCTION StandardEH( oError )
   LOCAL i, cMessage, aOptions, nOption, nSeverity
   LOCAL row, col
   LOCAL oDacSession, oSession
   Static nFehler_Stack := 0                    // HB

   if nFehler_Stack > 5
      quit
   endif
   nFehler_Stack++

[AUGE_OHR]

Kann man das irgendwie gescheit abfangen ?

einen Fehler abzufangen ist gut, aber die Frage ist doch warum der Fehler auftritt ?!

auch würde ich den Fehler nicht erst in der ErrorSys abfangen sondern schon in der "Net_Use"*** Function mittels BEGIN SEQUENCE / RECOVER.

Fragen :

was für ein OS() ?
verwendest du eine eigene DBESYS ?
wird die DBF "schnell" ( < 1 Sec. ) geöffnet ?
verwendest du KB150384 http://support.microsoft.com/kb/150384 ?
wird die DBF immer mit ALLEN dazugehörigen Indexen geöffnet ?
Indexe immer in der selben Reihenfolge ?
wurden die Index seit dem Start der Applikation neu erstellt ?

*** EINE Funktion zum öffnen von ALLEN DBF Dateien ( einzeln oder gemeinsam ) mit den dazugehörigen Indexen ( immer die selbe Reihenfolge ) im Netzwerk.

[Koverhage]

Jimmy,

das hat alles damit nichts zu tun. Wie Tom schrieb, ist der Virenscanner ursächlich dafür.

[Daniel]

Danke Hubert, Jimmy und Klaus!

Ja, ich verdächtige auch den Virenscanner (Kaspersky) und habe den Kunden schon mehrmals klar gebeten / aufgefordert, das ganze Datenverzeichnis von der ständigen Überwachung auszunehmen. Da er aber SEHR vorsichtig ist, meint er, es genüge, die DBFs als Ausnahmen einzugeben. Nun treten die periodischen Fehler "nur" noch bei Indizes und temp. Files auf ...

Tja, und da steht man vor der Frage, kann / soll ich versuchen, es dem Kunden zu beweisen, oder soll ich einen Ausweg suchen? Z.B. indem ich gemäss Toms oder Jimmys Rat den Fehler abfange, 3-5 weitere Versuche mache und dann hoffentlich das Problem los bin?

Übrigens habe ich auch noch bei Alaska nachgefragt, um möglicherweise dem Kunden etwas vorweisen zu können. Ich poste es hier, damit es möglicherweise auch noch andern Kollegen nützt.

Code: Alles auswählen

Wenn beim öffnen einer Index Datei ein Problem auftritt, dann wird ein Laufzeitfehler erzeugt der wie jeder andere Laufzeitfehler abgefangen und behandelt werden kann. Hierzu bietet Xbase++ die Schlüsselworte BEGIN SEQUENCE, RECOVER und ENDSEQUENCE. Bitte schauen Sie hierzu auch in der Doku unter BEGIN SEQUENCE.

Im wesentlichen hat die Fehlerbehandlung immer folgende Struktur:
// Jeder Laufzeitfehler Führt zu einem Break() das das Fehler Objekt 
// übergeben bekommt. Das Programm wird dann nach dem Recover fortgesetzt.
bSaveErrorBlock := ErrorBlock( {|e| Break(e)} )

BEGIN SEQUENCE
  ...
  OrdListAdd( cIndexFile )
  ...
RECOVER USING oError
  // Sofort nach dem Recover den Errorblock wieder zurück setzen. 
  //Jeder weitere Fehler beendet sonst den Thread mit Break()
  ErrorBlock(bSaveErrorBlock)
  // Behandeln des Fehlers
ENDSEQUENCE

// Auch im Erfolgsfall den Errorblock sofort restaurieren.
ErrorBlock(bSaveErrorBlock)

Ich hoffe das hilft ihnen weiter.
Mit freundlichen Grüssen,    Alaska Technical Support 

[brandelh]

Wenn er NUR Dateien ausnehmen will, sind die NTX mindestens genauso wichtig wie DBF, auch DBT etc. nicht vergessen.

[Tom]

Hallo, Daniel.

Kaspersky gehört nach meiner Erfahrung zu den biestigsten Virenscannern (außerdem noch: Avira). Kaspersky führt u.a. etwas durch, das "Prozessüberwachung" genannt wird und bei weniger vertrauenswürdigen (also nicht signierten oder gewhitelisteten) Programmen dazu führt, dass sogar der Dialogaufbau ausgebremst wird, ganz ohne Datenzugriffe. Wenn der Kunde schon sehr "sicherheitsbewusst" ist (was übrigens keineswegs vor neuen Viren und Trojanern schützt - auch die muss der Scanner erst einmal kennenlernen), sollte er wenigstens die anderen Suffixe (DBT/FTP, NTX/CDX, TMP, XPF usw., ggf. eigene Kreationen) in die Ausnahmedatenbank aufnehmen. Damit geht er kein Risiko ein - und Deine Applikation wird auch nicht mehr auf Fehler treten. Der nötige Beweise wäre also angetreten, ohne Programmieraufwand.

Das Alaska-Beispiel zeigt, wie man jeden beliebigen Vorgang kapseln und gegen Laufzeitfehler abschotten kann. Es wäre die abstrakte Vorlage für eine eigene Indexöffnungsroutine. Du müsstest also "USE ... INDEX ..." verbiegen (Präprozessor), was ein kleines bisschen aufwendig ist, alternativ OrdListAdd() durch eine eigene Funktion ersetzen (falls Du mit OrdListAdd() arbeitest, was grundsätzlich zu empfehlen ist), z.B. durch MyOrdListAdd. In dieser eigenen Funktion könntest Du dann die Öffnung der Indexe in eine Sequenz einbetten und den Öffnungsvorgang mit einer Latenz von z.B. 100 Millisekunden x Male wiederholen. Genau dasselbe ist aber auch direkt in der ErrorSys möglich - mit geringem Risiko für Fatals, wenn es keine exklusiven Nutzungen der fraglichen Tabellen und Indexe gibt. Denn der Index wird ja gefunden - er kann nur nicht geöffnet werden. Der Virenscanner generiert ein Timeout, weil er mit dem Scannen der Dateien nicht hinterherkommt. Der GenCode des Fehlers lautet "XPP_ERR_OPEN" und im "Args"-Array wirst Du den Namen einer Indexdatei finden. In dieser Variante kann die Errorsys ein Retry auslösen, ggf. gesteuert über einen internen Zähler, der zur Folge hat, dass nach x Versuchen doch noch die Standard-Fehlerbehandlung ausgelöst wird.

[Daniel]

Hallo, Jimmy

Ja, das wäre bestimmt gut, eine solche Routine in die "Net_Use" einzubauen.
Ich habe ja schon eine solche zum Öffnen der DBF.
In diesem Zusammenhang gibt es ja das Beispiel 2 unter "BEGIN SEQUENCE" in der XBase-DOKU, da könnte man etwas davon verwenden.

Die andere Variante wäre eben, alle Probleme beim Öffnen von Indizes in der ErrorSys abzufangen.

Ich sehe, was du meinst mit "Dateien 'schnell' öffnen - und dem KB150384 (auf XP).
Aber da lasse ich lieber die Finger von, denn der Kunde ist ein Stück weit weg und hat mehrere Filialen. Da hat er eigene System- und Netzwerkbetreuer. (Ich habe da schlechte Erfahrungen mit den SMB2-Geschichten!)

[Daniel]

Und warum kannst du das nicht zählen ?

ICH nutze dafür eine Static Variable, etwa so ...

Code: Alles auswählen

STATIC FUNCTION StandardEH( oError )
   LOCAL i, cMessage, aOptions, nOption, nSeverity
   LOCAL row, col
   LOCAL oDacSession, oSession
   Static nFehler_Stack := 0                    // HB

   if nFehler_Stack > 5
      quit
   endif
   nFehler_Stack++

Hallo, Hubert

ja, danke, das stimmt, mit einer STATIC Variable müsste das wohl gehen.
(Ich dachte, das wäre schwierig, wenn die FUNCTION StandardEH immer wieder neu durchlaufen wird ...)

Mal schauen, ob ich das so hinbekomme.

[Daniel]

Hallo, Tom

Ja, der Kaspersky hat mir schon öfter Kopfschmerzen bereitet ... - und ich werde das mit den Ausnahmen dem Kunden zum wiederholten Mal erläutern.

Es ist natürlich attraktiv, die Fehlerbehandlung so auszubauen, dass damit möglichst viele Probleme abgefangen oder wenigstens für den Anwender verständlich angezeigt werden (wie es eigentlich sein sollte ...).
Danke für die Tipps!
Ich werde mal schauen, ob ich das so hinbekomme.

Wenn man eine Applikation neu entwickelt, könnte man anderseits schon eine eigene Funktion zum Öffnen von DBF und Indizes bauen, so im Stil des erwähnten Beispiels unter "BEGIN SEQUENCE" in der DOKU.

[Tom]

Hallo, Daniel.

Du kannst das auch bei bestehenden Apps machen. Der Präprozessor erlaubt es, Kommandos wie "USE ..." oder "SET INDEX TO", die ja intern sowieso auf Funktionen "verbogen" werden (DbUseArea(), OrdListAdd()), auf eigene Funktionen umzuleiten, die die fraglichen DBE-Funktionen dann in Sequenzen eingebettet verwenden. Dafür genügen eine #command-Direktive in der fraglichen PRG (oder in allen) sowie eine zentrale Funktion, die dann die entsprechenden Tätigkeiten vornimmt. Solltest Du mit DbUseArea() und/oder OrdListAdd() arbeiten, genügten ein simples Search&Replace und die Ersetzung durch eigene Funktionen.

All das hat allerdings einen Haken. Der Virenscanner wird Deine App weiterhin mindestens ausbremsen. Man bekämpft Symptome, nicht aber die Ursachen.

[Tom]

Präprozessor-Beispiel:

Code: Alles auswählen

#command  USE <(dbFile)> ;
          [VIA <dbe>] ;
          [ALIAS <alias>] ;
          [<new: NEW>] ;
          [<exc: EXCLUSIVE>] ;
          [<sav: SAVE>] ;
          [<vsv: VERYSAVE>] ;
          [<sha: SHARED>] ;
          [<reo: READONLY>] ;
          [INDEX <(index1)> [,;
                 <(indexN)>]] ;
      =>  MyDbUseArea( .T., <(dbe)>, <(dbFile)>, <(alias)>, ;
                    iif(<.sha.> .or. <.exc.>, !<.exc.>, NIL), <.reo.>) ;
          [; MyOrdListAdd( <(index1)> )] [; MyOrdListAdd( <(indexN)> )]

Das leitet "USE ... INDEX ..." auf die Funktionen "MyDbUseArea" (für die Tabelle) und "MyOrdListAdd" (für die Index) um. Im einfachsten Fall werden dort schlicht die Pendants (DbUseArea und OrdListAdd) mit den entsprechenden Parametern aufgerufen. Man kann aber auch in "MyDbUseArea" z.B. NetErr() ein paar Male abfangen oder in diesem Fall einen Dialog anzeigen. Und man kann in OrdListAdd mit einer Sequenz arbeiten und die Öffnung der Indexdatei einige Male versuchen. Das sind insgesamt vielleicht 30 Zeilen Code, und man muss, um ihn zu aktivieren, nichts weiter tun, als die o.g. Direktive einzubinden.

[Daniel]

Danke, Tom

ich werde das gerne studieren.

[AUGE_OHR]

das hat alles damit nichts zu tun. Wie Tom schrieb, ist der Virenscanner ursächlich dafür.

klar, Virenscanner hatte ich ausgeschlossen.

ich gehe nun von dem selben Fehler aus der auch ohne Virenscanner auftreten könnte und welche "möglichen" Problem es sein könnten.

[AUGE_OHR]

Präprozessor-Beispiel:

=D>
... aber das ganz erfordert das der bestehende Code "sauber" ist.
Ich habe damit zwar dann die Function MyDbUseArea() aber noch kein ELSE in meinem Code

Code: Alles auswählen

Cl*pper SINGLE User Code
   USE AAA ...
   IF !NETERR()
       SET INDEX TO ...
   ELSE
       // Fehler ... und was nun ?
   ENDIF

wird zu

   IF NET_USE("AAA" ... )

   ELSE
       // Fehler abgefangen
       RETURN .F.
   ENDIF

bei NTX Indexen wird ja jeweils eine Datei angelegt. Wenn man nun viele Indexe zu einer DBF hat und diese überall im Code "verstreut" sind dann kann das schon mal vorkommen das man an einer Stelle vergessen hat den neuen Index ein-zu-pflegen ...

[Tom]

Hallo, Jimmy.

MyDbUseArea() könnte etwas ähnliches tun wie NetErr(), nämlich schlicht eine Get-Set-Funktion aufrufen und bestücken.

Code: Alles auswählen

FUNCTION MyDbUseArea()
LOCAL lDbOpened := .F.
BEGIN SEQUENCE 
...
* bei Erfolg: lDbOpened := .T.
...
END SEQUENCE
MyNetErr(lDbOpened)
RETURN NIL

FUNCTION MyNetErr(lDbOpened)
STATIC lOpenError := .F.
IF PCount()>0
  lOpenError := !lDbOpened
ENDIF
RETURN lOpenError 

Nach einem "MyUseDbArea()" ruft man - analog zu NetErr() - einfach MyNetErr() ab, feddisch. Ließe sich ergänzen und ausbauen, z.B. ergänzt um analoge Funktionalitäten für OrdListAdd(). Und schon hat man ein sicheres, stabiles System, das man außerdem mit Selbstlernfähigkeiten ausstatten könnte, etwa für die zu wählenden Latenzen bei Öffnungsfehlern und ähnlichem.

[Bernd Reinhardt]

Hallo

Ich habe auch das Problem bei einem Kunden und hab hier mal bei mir einen Testaufbau gleich mit Version 2.0 gemacht.
Dbf-Ntx Dateisystem, Programm und Daten liegen auf einer NAS über Laufwerksbuchstaben: z:\meintest
Kaspersky Virenscanner
WIN 8.1, xBase++ 2.0
Index wird mit dem Befehl OrdCreate erstellt.
In der Regedit (SMB2 filecache usw. habe ich nicht auf 0 gesetzt).

set exclusive on und Kaspersky ein:
Hier kommt beim Indexaufbau ständig der Fehler und kann mit wiederholen weitermachen.
Die Indexe werden auch erstellt.

set exclusive on und Kaspersky aus:
Indexaufbau ohne Fehlermeldung

set exclusive off und Kaspersky an:
Indexaufbau ohne Fehlermeldung.

Das ganze mal mit den SMB2 Einstellungen (filecache usw. )
Selbe Meldungen wie ohne die drei Einträge.

Scheint doch auf Kaspersky hinzudeuten.

Gruß
Bernd

[AUGE_OHR]

Dbf-Ntx Dateisystem, Programm und Daten liegen auf einer NAS über Laufwerksbuchstaben: z:\meintest

hm ... NAS ... die haben nur SMB1

In der Regedit (SMB2 filecache usw. habe ich nicht auf 0 gesetzt).

die 3 Einträge sind unter

Code: Alles auswählen

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters

also für die Workstation ... und was hast du für den Server als SMB Einstellungen ?

Scheint doch auf Kaspersky hinzudeuten.

dann schmeiss den Scheiss doch raus !

[brandelh]

Es wurde schon mehrfach erwähnt, bleibt aber immer noch wahr.
DBF, DBT, NTX, CDX, etc. Dateien dürfen NICHT vom Virenscanner gescannt werden, das muss schiefgehen.

[DelUser01]

Hallo

Der "normale" Virenscanner bearbeitet DBF, NTX u.ä. nur wenn der User das explizit einstellt. Wie z.B.:
[X] alle Dateien scannen (o.ä).
Hatte dieses Problem mit Virenscanner noch gar nie (never say never...)
Ausnahme für DBF, NTX muss man nirgends einstellen - die Virenscanner-Hersteller sind ja auch nicht von gestern.

[Koverhage]

Roland,

aber von Morgen. Die Probleme tauchen erst dann auf, wenn Pro aktiver Schutz / Heuristic eingestellt ist.

[brandelh]

Also soweit ich mich erinnern kann, hatte weder Avira noch Bitdefender Ausnahmen für die Dateien,
aber es ist schon eine Weile her

Auf keinen Fall hatte ein Virenscanner eine DBF etc. bei mir als problematisch gemeldet,
aber ab und zu waren Dateien blockiert wenn man sie bearbeiten wollte, das war mit dem Hinweis auf Virenscanner gemeint.

Die Probleme tauchen erst dann auf, wenn Pro aktiver Schutz / Heuristic eingestellt ist.

genau ... OBJ, EXE gelöscht oder gar nicht erstellt ...