Board index » Visual Studio » Program crashes with ODBC call Any helpful advice is appreciated

Visual Studio269
I am having a program with ODBC call to insert a record using the

ExecuteSQL statement.

The code is as follows

//-----------------------------------------------

CDatabase db;

if(db.OpenEx(DSNName,0)== 0)

{

AfxMessageBox("Error opening database");

return;

}

try

{

db.ExecuteSQL("INSERT INTO XYZ VALUES(x1,x2,x3)");

}

catch(CDBException *pExc)

{

AfxMessageBox(pExc->m_StrError);

}

//------------------------------------------------

The program raises an exception when I am trying to insert a duplicate

record. However when I am trying to handle the exception of type

CDBException the program crashes in the exception handler or sometime

afterward.

Sometimes the error message is access violation and sometimes the

program just hangs.

The program also crashes at some other times. After checking the

program thoroughly I've come here.

Please give advice.



D.Ramesh


-

What operating system do you use, and what version of Visual Studio?



Is the application multithreaded?



Regards,

Oleg









-

"Oleg Starodumov" <oleg_staro@hotmail.com>wrote in message news:<O8DLAFvpEHA.1668@TK2MSFTNGP14.phx.gbl>...

I am running Win 2000 and the application is multithreaded, the

database I use is MS - Access I use Global flags to synchronise

concurrent access to the database(from any thread waiting in loop

until the flag says not busy anymore). I created a single threaded

version but that also crashed.

Thanks,

Ramesh

-

What Visual Studio version is used?



Regards,

Oleg









-

Actually, regardless of Visual Studio version used,

I would ask you to:



1. Enable as much runtime and system checks as possible

(runtime checks: /GZ (VC6), /RTC1 (VS.NET), /GS(VS.NET))

(system checks: Full PageHeap)



2. Reproduce the problem and post here the call stack

at the moment of the exception (or call stacks of the relevant threads

at the moment of hangup).



You will likely also need good symbols for system DLLs

to get good call stacks.



Oleg







-

On 30 Sep 2004 03:19:57 -0700, rdeekonda@hotmail.com (Deekonda Ramesh) wrote:



some pointers:



try using == FALSE or !db.OpenEx( DSNName, 0 ) instead

since it is a BOOL that is returned.



try using reference instead of ptr in catch - statement -

avoids the question about who owns the exception.



catch (CDBException &Exc)

{

AfxMessageBox( Exc.m_StrError );

}



try adding a catch(...) to get any unexpected surprises



catch(...)

{

AfxMessageBox( "Oops" );

}



hth/ak

--

You are only young once, but you can stay immature indefinitely.

-

ak <ak@workmail<dot>com>wrote in message news:<pmhql0t2fu423oadphjdcl9sakcak1rscq@4ax.com>...



The switch /GZ is allready enabled in my application.

The callstack was something like this

MSCTF

NTDLL

NTDLL

NTDLL

NTDLL

The NTDLL going down a 100 times sometimes. Some times the call

stack(about 3 calls deep has MSJET at bottom of stack.I have not yet

tried out the catch(...) because I need to hook up a modem to test my

program.

Regards,

Ramesh

-

You don't have symbols for system DLLs, so the call stack is not too

meaningful. The case with NTDLL repeated 100 times is most likely

a stack corruption, but I would first suspect an application bug for

making the initial damage (e.g, corrupting the heap).



Try to enable Full PageHeap and run the application under debugger.

If there is a heap corruption detected, you will be notified via

an access violation or a hard coded breakpoint.



You said you can reproduce the problem with a single-threaded version

of the application, so I would recommend to try the single-threaded version first.



To enable PageHeap, set this Registry entries:



HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourApp.exe

GlobalFlag = REG_DWORD 0x2000000

PageHeapFlags = REG_DWORD 0x3

(replace YourApp.exe with the real name of your application's executable)



It is better if you test the application when it is linked to non-Debug CRT library.



More information about PageHeap:

http://support.microsoft.com/default.aspx?scid" rel="nofollow" target="_blank">support.microsoft.com/default.aspx=kb;en-us;286470



To get more meaningful call stacks, you need symbols for system DLLs

loaded by the application (at least for the ones listed on the call stack).

The best way to get symbols is to download them from the symbol server.

VS.NET debugger can download symbols automatically, but since I guess

you use VC6, you need a separate tool. For example, this one:

www.debuginfo.com/tools/symget.html">www.debuginfo.com/tools/symget.html



I would not recommend it. It will only hide the problem, but will not help to fix it.



Regards,

Oleg





















-

"Oleg Starodumov" <oleg_staro@hotmail.com>wrote in message news:<efj#N1gqEHA.3800@TK2MSFTNGP14.phx.gbl>...



The problem seems to have sorted itself out. The reason for the

problem is still not clear. I did find a memory bug in my code but in

a portion of the program not being generally executed.I will try out

the other suggestions also. Temporarily atleast it is working .Thanks

everybody especially oleg for the helpful advice.

Regards,

D.Ramesh

-

rdeekonda@hotmail.com (Deekonda Ramesh) wrote in message news:<868c2cc.0410082339.71f8f855@posting.google.com>...

Problem seemed to appear on concurrent access of database - MsAccess,

MSAccess probably doesnt support concurrency.The main problem is

however gone for now.

-