Nicht abgefangene Ausnahme in Meiner.exe (KERNEL32.DLL): 0xE06D7363: Microsoft C++ Exception.
-
Hallo!
Wie finde ich raus, WO diese Ausnahme ausgelöst wird? Sie hängt mit den Datenbankzugriffen zusammen, aber ich finde sie nicht.
Selbst bei ordentlich gesetzten try...catch Blöcken tritt sie auf. Ich bin ratlos...
Und es ist auch nicht jeder Zugriff betroffen.
Das 0xE06D7363 ist immer das Selbe - hilft mir das was? Und was?
-
mal mit dem debugger durchgehen???
Esco
-
Das ist die Variante, an der ich jetzt schon seit Wochen immer wieder sporadisch arbeite - erfolglos.
Aktueller Stand: Es passiert bei einem MoveNext im Recordset.
// Vorne anfangen MoveFirst(); while((!IsEOF()) && (!fReturn)) { // Stimmt die Kombination? if (GetID() == f_lID) { fReturn = true; } if (!fReturn) { MoveNext(); // <------- DA! } }Edit: Wenn ich die Zeile so sicher mache, wie mir nur möglich und bekannt ist, dann kommen die Traces trotzdem noch.
try { MoveNext(); } catch (CDBException* e) { CLog::Log(LOG_NR_DB_FEHLER, e->m_strError); throw(e); // Weiterwerfen } catch (...) { TRACE("Erwischt"); }
-
Und was passiert in MoveNext?
-
Soll ich dir den Quellcode der MFC an der Stelle rauskopieren oder was meinst du?
Diese doofe Funktion wird zig Hunterte Male aufgerufen OHNE dass der Fehler auftritt.
MoveNext wird noch DEUTLICH häufiger aufgerufen.Einzeln da durchdebuggen ist doch wohl nicht die einzige Lösung, oder? Da sitze ich da nächstes Jahr noch hier und drücke F11.
-
Wenn du keine CDbException bekommst, dann wird wohl keine geworfen werden. Du arbeitest schon mit CDatabase und nicht mit DAO? Sonst mußt du nämlich CDaoException fangen.
Ansonsten solltest du doch in der Aufrufliste dahinterkommen, was für 'ne Exception geflogen ist, oder irre ich da?
-
Starte mal den Debugger, dann wählst du "Debug"/"Exceptions". Unten in der Liste steht "Microsoft C++ Exception".
Wenn du das auf "Stop always" stellst, bleibt der Debugger genau an der Stelle stehen, wo die Exception ausgelöst wird.
-
@Uwe Philipps: Super! Das kannte ich ganz ehrlich noch nicht.
@TheBigW: Ich nutze ODBC. Wie du siehst, habe ich es ja sogar mit catch(...) versucht, was auch nicht hilft.
So, ich hänge jetzt in der Zeile
RETCODE CRecordset::FetchData(UWORD wFetchType, SDWORD nRow, DWORD* pdwRowsFetched) { RETCODE nRetCode; if (m_nOpenType == forwardOnly && !(m_dwOptions & useExtendedFetch)) { ASSERT(wFetchType == SQL_FETCH_NEXT); AFX_ODBC_CALL(::SQLFetch(m_hstmt)); *pdwRowsFetched = 1; m_bDeleted = FALSE; } else { AFX_ODBC_CALL(::SQLExtendedFetch(m_hstmt, wFetchType, nRow, pdwRowsFetched, m_rgRowStatus)); // <-------- // Set deleted status m_bDeleted = GetRowStatus(1) == SQL_ROW_DELETED; } CheckRowsetError(nRetCode); return nRetCode; }Das ist die letzte "lesbare" Funktion im Callstack, der Rest ist Assemblercode.
Jetzt muss ich noch irgendwie rausfinden, WAS ihm nicht passt, WARUM und wie ich das loswerden kann.
-
Hm, wenn ich mich richtig erinnere, wirft MoveNext eine Exception wenn
man versucht über das Ende des Recordsets hinaus zu lesen.
-
mhh und wenn du erstmal bloß als CException fängtst? Dann solltest du eventuell über die Errormessage schon mal raus kriegen, was faul ist.
-
@Devil: In meinem Post von 09:59 siehst du, dass ich auf EOF prüfe - das sollte doch reichen, oder?
Okay, ich versuche es jetzt mal, ob er als CException was fängt. Auch wenn ich skeptisch bin, wo doch selbst ... nix erwischt hatte.
-
Hi,
der Gedanke von devil ist nicht schlecht - ich prüfe in meinem Programm, in dem ich auch CRecordsets verwende, immer mit der Kombination IsBOF und IsEOF - vielleicht solltest Du das mal checken - IsBOF fängt laut MSDN noch ein paar Fälle ab, die IsEOF nicht kriegt...
Gruss
yeti
-
Hier ist nochmal die ganze Schleife:
// Einmal über alle Datensätze laufen if (IsBOF()) { } else { // Vorne anfangen MoveFirst(); while((!IsEOF()) && (!fReturn)) { // Stimmt die Kombination? if (GetID() == f_lID) // Hier MUSS GetID() statt m_lID stehen, sonst funktioniert das Suchen nicht!!! { // Die ID merken fReturn = true; } if (!fReturn) { try { MoveNext(); } catch (CException e) { TCHAR szCause[255]; CString strFormatted; e.GetErrorMessage(szCause, 255); TRACE(szCause); } } } }Reicht das eine IsBOF nicht? Ich bewege mich doch vom BOF weg, oder?
Naja, wenn du sagst, da steht was in der MSDN, dann muss ich wohl mal gucken.Die Exception wird übrigens so, wie es da steht nicht gefangen.
Habe ich was falsch gemacht?
-
Hi,
in Deinen vorherigen Postings habe ich das IsBOF nicht gesehen - sorry!
So wie das hier aussieht, scheints es ganz ok zu sein. Hast Du mal gecheckt, ob und wie oft Du mit welchen Daten in die MoveNext-Ecke reinkommst?
Wie wird fReturn initialisiert?
gruss
yeti
-
catch (CException***** e)
-
Ich hatte das IsBOF ja auch weggelassen.
Ich habe das eher so als Überbleibsel an der Stelle - ohne gab es sonst auch nie Fehler...
fReturn wird mit false initialisiert (Sorry, DAS hätte ich wirklich noch mitposten sollen.)
Die MoveNext wird extrem häufig angesprungen und auch in 99% ohne Fehler.
In der Funktion suche ich nämlich per ID nach einem Datensatz - das brauche ich ständig.
TheBigW schrieb:
catch (CException***** e)
Nein, sie wird ebenfalls nicht gefangen.
-
Also wenn catch(...) nichts fängt würde es mich ja wundern, wenn irgendwas anderes dann was fangen würde...
-
Mich ja auch, aber ich hab ja schon gesagt, dass ich davon kaum Plan habe, also versuche ich es einfach mal.
Wenn ich keine Ahnung habe, haben andere meistens erstmal Recht.
Ich habe jetzt mal mitzählen lassen und die Traces angeschaut. Ich kann kein Schema erkennen, jedenfalls nichts, was mit der Anzahl der Aufrufe zu tun hat.
Außer, dass die erste Ausnahme (die anderen habe ich noch nicht verglichen) immer bei Nr. 736 fliegt und das im Doppelpack.
Aber seht selbst, ich habs mal hochgeladen: http://www.larsaf-iii.de/forum/trace.txt
-
Hm... Ist der Datensatz vielleicht korrupt?
-
Naja, auf jedenfall würde ich jetzt mal den MoveNext bei dem es das erste mal kracht (und den kennst du jetzt ja, wenn cih das richtig verstanden hab) einfach mal durchdebuggen. Dann hast du vielleicht nen Anhaltspunkt, woran es liegen könnte.