XProfan

Die Frage ist leider ungültig. Dos und Windows reagieren - aus der Deinigen Perspektive betrachtet - beide mit Abbruch/Absturz.

on error kann auch nur warnings abgefangen haben welche fälschlicher Weise als Errors bezeichnet wurden - da echte Abstürze ja nunmal eine weitere Abarbeitung verhindern (sonst wäre es kein Absturz

) - unter Dos und Windows!

Es liegt also an Dir - unter Dos und unter Windows - ein Programm derart zu schreiben das kein Systemfehler auftritt.

Fehler bleibt Fehler - da hilft auch kein Dos/Windows.

GDL

Tut mir leid,

aber ich habe 15 Jahre mit DOS Programmen von Siemens,Bosch,Motorrola und SEL Funkgeräte und Radargeräte programmiert.
Da wir auch die Software abändern mussten,hatten wir auch den Quellcode dazu.

Kein Funkgerät oder Radargerät durfte wegen Dateifehler beendet(besser ausgedrückt wie Absturz) werden.

Unter DOS wird kein Programm mittels on error bei Dateifehler BEENDET oder die Bayerische Polizei hat ein anderes DOS in ihren Geräten.

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

RGH

Wenn es um Dateifehler geht, also I/O-Fehler, dann sollte man nach jeder Dateioperation %IOResult abfragen. Ganz genauso, wie schon damals unter DOS bei Turbo-Pascal. Ganz besonders wichtig ist das nach dem Öffnen einer Datei mit Reset, Rewrite, Append oder OpenRW. Aber auch bei den anderen Dateibefehlen und -funktionen, die eine Dateinummer benötigen, kann das nicht schaden. Ein Absturz bei fehlerhaften Dateioperationen sollte sich durch geschicktes Programmieren sicher vermeiden lassen.

Sicher war unter DOS in dieser Hinsicht manches einfacher, weil das laufgende Programm immer der einzigste Prozess war. Unter Windows ist das alles natürlich viel komplexer, da immer schon zig Prozesse am Laufen sind.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

GDL

Hallo Roland,

es geht nur noch um Hardwarefehler(grossteils beschädigte Dateien die sich aber noch öffnen lassen und dann den Crash verursachen) oder Verschluckfehler bei gelesenen Daten.

Habe mich schlau gemacht: BOS (Behörden,Organisationen mit Sicherheitsauftrag) verwenden das Siemens/Nixdorf DOS, was immer das auch sein mag ,es verwendet die selbige Befehlssyntax und doppelte Redundance(Absicherung? 2mal Start?).

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

RGH

[quote:6d37fd1a76=GDL]es geht nur noch um Hardwarefehler(grossteils beschädigte Dateien die sich aber noch öffnen lassen und dann den Crash verursachen) oder Verschluckfehler bei gelesenen Daten.[/quote:6d37fd1a76]
Bei welchen XProfan-Befehlen und -Funktionen treten die Fehler mit den beschädigten Dateien auf? Vielleicht kann ich die dann intern noch etwas robuster gestalten.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

GDL

Hallo Roland,

vielen Dank für dein Mithelfen.Bei 90% ist es der Befehl dbget$(feld).Ist auch korrekt da der Datensatz beschädigt.

1Versuch :
seterrolevel -1 und zu hohe Satznummer

Ergebnis : Programm läuft weiter, was ok ist.

2 Versuch
seterrolvel -1 auslesen beschädigter Datei

keine Fehlermeldung , Programm ist beendet und send Problem to MS

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

RGH

Ah, es geht um dBase-Dateien. Da hilft mein Hinweis auf %IOResult natürlich nicht weiter.

Was passiert bei Errorlkevel 0? Im ersten Fall müßte eine Fehlermeldung hochkommen. Was passiert im zweiten Fall? Kommt da eine Fehlermeldung vor dem Absturz?

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

GDL

Hallo Roland,

also im seterrolevel 0 kommt die Fehlermeldung Kann Feld nicht finden:xyz

seterrolevel 1 : keine Fehlermeldung,Programm wird beendet und die Sendenachfrage.

Normalerweise wäre es ja nicht so wichtig, da man bei Programmstart ja alle Daten und die nachfolgenden Änderungen in Variablen einlesen und bei Programmende wieder rücksichern könnte.
Nur da der PC über 3 Schnittstellen, davon eine direkt auf dem Systembus betrieben wird, wird bei Kurzschlüssen in der Anlage zur Sicherheit aller Hardwareteile die 220 Volt Leitung gekappt.Somit sind auch die Daten im speicher weg.

Habe das ganze so zu lösen versucht:
- Steuerung liest Daten in Variablen ein und gibt diese auch an die Zwischenablage.
- ein parallel dazu laufendes Programm schreibt dann Änderungen aus der Zwischenablage in die dazugehörigen Dateien auf Platte.
Somit käme bei einer beschädigten Datei nicht das Hauptprogramm zum Stehen und bei einem Kurzschluss wären die Daten auf Platte.

Leider macht Windows aber keinen zeitlichen 1 zu 1 Zugriff, sonder sammelt erst ne Menge Daten bevor Zugriffe stattfinden.
Somit ist ein zeitliches 1 zu1 Sichern eh nicht möglich,aber immerhin konnte die Sache mit der defekten Datei umschifft werden.
Bei Kürzschlüssen muss nun eine knifflige Portsicherung auf Hardwarebasis her, damit der PC nicht mehr entsaftet werden muss (sehe jetzt schon Rauchzeichen).

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

14.05.2006 ▲

Frank
Abbing

[quote:0c805ad06f]Leider macht Windows aber keinen zeitlichen 1 zu 1 Zugriff, sonder sammelt erst ne Menge Daten bevor Zugriffe stattfinden.
Somit ist ein zeitliches 1 zu1 Sichern eh nicht möglich,aber immerhin konnte die Sache mit der defekten Datei umschifft werden.[/quote:0c805ad06f]
Auf vielen Gebieten gibt es aber API, um manuell Zugriff zu erzwingen. Ala GdiFlush(). Eventuel lohnt es sich mal, in der WinDoc nach ähnlichen API für Dateioperationen zu suchen. FlushFileBuffers() scheint mir da vielversprechend zu sein.

14.05.2006 ▲

RGH

[quote:d8e65bacb6=GDL]Hallo Roland,

also im seterrolevel 0 kommt die Fehlermeldung Kann Feld nicht finden:xyz

seterrolevel 1 : keine Fehlermeldung,Programm wird beendet und die Sendenachfrage.
Servus
Georg[/quote:d8e65bacb6]
So wie es aussieht, erfolgt der Absturz nicht in der Funktion dbGetField$, sondern nachdem diese den Fehler verursacht in weiteren db-Funktionen.

Bei SetErrorLevel -1 sollte man nach jeder Funktion, die einen Fehler verursachen
könnte, diesen abfragen und entsprechend reagieren. Dazu gibt es die Systemvariablen %Error und %ErrNumber. Wenn bei dbGetField$() ein Fehler aufgetreten ist, also %Error und %ErrNumber (Bedeutung siehe Hilfe) entsprechend gesetzt ist, sollte reagiert werden. Wenn ein Feld nicht gefunden wurde, sollte jedes weitere Lesen dieser Tabelle vermieden werden, da sie offensichtlich defekt ist.

Unabhängig davon will ich mal schauen, wie man das Ganze etwas robuster gestalten kann.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

14.05.2006 ▲