C/ODBC and .NET error: protected memory exception

CuypzCuypz Member Posts: 56
Hi there,

The following exceptions are thrown randomly while running the application in the situations described below.

StackTrace wrote:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

at System.data.common.unsafeNativeMethods.SQLExecDirectW (...)
at System.data.odbc.odbcCommand.ExecuteReaderObject(...)
at System.data.odbc.odbcCommand.ExecuteReaderObject(...)
at System.data.odbc.odbcCommand.ExecuteNonQuery(...)


And this error I am unable to catch whatsoever:
StackTrace wrote:
Unhandled Exception: System.Runtime.InteropServices.SEHException: External component has thrown an exception.

at System.data.common.unsafeNativeMethods.SQLFreeHandle(...)
at System.data.odbc.OdbcHandle.ReleaseHandle()
at System.runtime.interopservices.safehandle.InternalFinalize()
at System.runtime.interopservices.safehandle.Dispose(...)
at System.runtime.interopservices.safehandle.Finalize()


While developing a .NET console application to insert some numbers automatically into a Navision US 3.70 database (running on 4.0 SP1), we've come across an error we were unable to solve up until now.

When we run our application locally on a testing database running on Windows XP Professional, everything works fine. The problem occurs when we migrate our application to the Windows Server 2003 environment.

We tried our application on a database running through a database server and on a local, single user database on this server, but both of them made the same error occur. Therefore I don't think it's a locked table error or something like that.

Since the errors never occurs locally, it can also not be a programming error, otherwise the error would also occur while testing on my local machine.

The only idea I have left is that the problem occurs because we connect to the server via Remote Desktop Connection. When logged in, we run this executable. Could this be causing the problems? It would be very strange, because we have made another .NET console application that reads data from the Item table of a running database using the same C/ODBC technique and no error ever occurs, even while executing through Remote Desktop.

Reading data works perfectly, even on the server, to which we connect via Remote Desktop, but when we try to do the same for inserting data to the Navision database, it fails.

As stated above, we are running a US 3.70 database on a 4.01 client. The C/ODBC version is also 4.01, otherwise I believe it wouldn't work at all. I am developing in MS Visual .NET 2005 Express Edition, which means that the applications I create run under the .NET Framework 2.0.

Any ideas, help, tips or tricks would be very much appreciated.


Thanks in advance!



Maarten

Answers

  • CuypzCuypz Member Posts: 56
    anybody?
  • CuypzCuypz Member Posts: 56
    We're still working on this problem and noticed that the memory usage of our console application is rocketing from 0 to ? in no time, while the application itself disposed of all unused objects and actually isn't doing anything else but inserting values into the database. I'm afraid we're dealing with a memory leak in the C/ODBC driver. Perhaps someone can confirm this?

    We got the feeling of a memory leak when we received the "Memory Allocation error" when compiled under the .NET 1.1 Framework.
  • CuypzCuypz Member Posts: 56
    The problem has been solved! It appears that the .NET Garbage Collector wasn't doing a thorough job, but by manually starting the GC, the memory leak disappeared.
  • Tan_Eng_SiongTan_Eng_Siong Member Posts: 84
    Hi

    Could you let me know how do you connect a 3.7 database to a 4.0 SP1 ODBC and client? I am encountering the same error message but I do not want to upgrade the users to 4.0 SP1? The users are on 4.0 w/o Service packs.

    The NET developer keeps insisting it is a NODBC error. Is running the Garbage Collector a difficult or time cosuming chore?

    Thanks

    Tan Eng Siong
    Tan Eng Siong
Sign In or Register to comment.