vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
NEU! sevCoolbar 2.0 - Professionelle Toolbars im modernen Design!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   RSS-Feeds  | Newsletter  | Impressum  | vb@rchiv CD Vol.5  | Shop Copyright ©2000-2008
 
zurück
Knüller: vb@rchiv CD Vol.4
Knüller: vb@rchiv Offline-Reader - Die Offline-Wissensdatenbank

vb@rchiv Offline-Reader - exklusiv auf der vb@rchiv CD Vol.4
 
Tools & Components Anzeigen 
 
Unser Tipp: Alle Online-Forenbeiträge aus dem vb@rchiv - gesammelt in einer Offline-Wissendatenbank, mit Internet-Update-Funktion, u.v.m.

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

C# Ecke
Re: Eine Vermutung 
Autor: ModeratorDaveS (Moderator)
Datum: 30.05.08 21:29

Hi Drapondur,

Ich danke dir. Sowas habe ich mir auch lange überlegt. Dieser Code läuft ca 4 Jahre ohne Problem, plötzlich kommt dieser Fehler. Es gibt eine neuere Version wo ein Wert -1 abgefangen wird mit Exception aber der Kunde fährt noch die uralte Version. In der Tat würde nur -1 als Parameter eventuell stören, weil -1 "leeren Eintrag" bedeutet. Die Werte sind File Handles, und -1 würde bedeuten Open() schlug fehl, aber dann wird nichts eingetragen. Aber wenn schon, wäre das ein Null-Eintrag, was vielleicht überschrieben wird, im schlimmsten Fall dann beim Schliessen und Löschen des Eintrags könnte ein Fehler kommen wenn zufällig alle Felder besetzt sind und kein -1 übrigbleibt, aber das scheint nicht der Fall zu sein. Ich habe auch einen multithreading Testtreiber was den Code mit 20-30 "gleichzeitige" Zugriffe bombardiert aber nichts schlimmes passiert. Es ist alles sehr mysteriös. Wir haben den Server ganz neu eingerichtet und das Problem ist jetzt weg, aber nicht wirklich behoben.

Das ganze ist entstanden weil wir beim File-Open in MT Umgebung manchmal duplizierte Handles bekommen haben, was für mich auf einen schwerliegenden Fehler in .Net Threads hinweist. Das Problem war weg nachdem alle .Open() und .Close() mit Lock() serialisiert wurden (nicht sehr schön, natürlich), aber wir haben dann diesen Code geschrieben um alle Filehandles zu merken und feststellen zu können ob sowas wieder passiert. In der Tat hat der Code nie einen Fehler abgefangen, nur hat der Code selber jetzt einen Fehler verursacht, was ja sehr ironisch ist, ha ha. Ich werde den ganzen Code wahrscheinlich löschen. Trotzdem möchte ich schon wissen was da wirklich passiert.

________

As per standard protocol the intelligence findings were fixed in advance by policy

alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
IndexOutOfRangeException409ModeratorDaveS29.05.08 14:34
Re: IndexOutOfRangeException158ModeratorDaveS30.05.08 08:14
Eine Vermutung143Drapondur30.05.08 19:42
Re: Eine Vermutung141ModeratorDaveS30.05.08 21:29
Re: Eine Vermutung132ModeratorDaveS30.05.08 21:33
Re: IndexOutOfRangeException130ModeratorDaveS31.05.08 15:22
Re: IndexOutOfRangeException136spike2402.06.08 09:31
Re: IndexOutOfRangeException130ModeratorDaveS02.06.08 09:48

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2008 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.

Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel