Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Attempt to read or write protected memory
Message
General information
Forum:
ASP.NET
Category:
Other
Environment versions
Environment:
VB 8.0
OS:
Vista
Network:
Windows XP
Database:
Jet/Access Engine
Application:
Desktop
Miscellaneous
Thread ID:
01502676
Message ID:
01502731
Views:
34
Excel is a feature of COM, no doubt, but my intension to use it is not :)

But I think I know where I should be looking. I'm opening a connection (oledb, I can hear you go "theeeeere ya go") in the new() method and I have not figured out how to close it yet.

For reasons that slowly but surely become clear, I get a "no handle" runtime error when issue
        If Me.da.Connection.State = ConnectionState.Open Then Me.da.Connection.Close()
when the garbage collector (so I gather) calls the finalize method, when I close the application.

In itself this sounds like catch 22, don't you think? I mean you would expect that if a connection state is open it also has a handle.

Now since the connection was not closed properly, I can imagine that my system is left unstable, which explains the errors I experience.

I understand that I could implement the IDisposable interface. But I'm not sure it's worth the trouble, as, as I understand I need to call
the dispose method myself, it won't be triggered when the object goes out of scope (as it does not really get destroyed when it goes out of scope). Then I might write a close_connection method and call that when the form is closed.

I guess that what I'm really asking is "Is there such thing as vfp destroy that gets executed when the object is released, or out of scope?"

From the business class that handles the connection...
Public Class bzArtikel
    Dim ds As New dsArtikel
    Dim da As New dsArtikelTableAdapters.ArtikelTableAdapter
    Public dt As New dsArtikel.ArtikelDataTable
    Dim pk As Long
    Public Record As dsArtikel.ArtikelRow
    Public Sub New()
        Me.da.Connection.Open()
    End Sub
    Protected Overrides Sub Finalize()
        If Me.da.Connection.State= ConnectionState.Open Then Me.da.Connection.Close()
        MyBase.Finalize()
    End Sub
From the class the instatiates :
Imports System.Data.OleDb
Public Class Bestelfrm
    Inherits frmB040
    Dim obzArtikel As bzArtikel
Finally (finally?) I want to explain why I need to do this: I found out that opening a connection is a slow process. I have found out that when I pull up a document for which i need my business object to access the db, it is much more effective if you open the connection once, than when you open the connection for each record.

>It's a feature of COM. :-}
>Once you venture out of the .NET box and use unmanaged code you are potentially exposing yourself to the same old problems.
>Are you using any COM objects (or third part .NET classes that do so) ?
>Any direct Win API calls ?
>
>As before, I'm not claiming those *are* the source of the problem - just that it you are using them then that should be the first place to look.
>If you're not using COM then perhaps you can provide a bit more detail about when the error occurs.
>When you say 'in development' do you mean when running the app in debug mode ?
>What's the app? - Winforms, ASP.NET etc....
>
>
>>O so this is a feature? And I thought that the "code and pray" days were behind us.
>>
>>My problems started when I added a New to one of my business classes. I have the intention to use excel, but surely, Viv, that does not count, does it :).
>>
>>Thanks.
>>
>>>>>I'm getting this error only in development, in certain circumstances.
>>>>>
>>>>>Should I worry? :)
>>>>
>>>>Yes. Check very long discussion
>>>>http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/6adca20b-649f-41a4-8fa1-09534882d76c
>>>
>>>Certainly a long discussion. But only one post of any merit (James Kovacs , 9/18/2006) and one section in there that shows why most other suggested solutions were not solutions at all:
>>>
>>>"You will also see small changes (like changing compiler optimizations, or re-ordering instructions) cause code to start working. What you've done is mask the problem. The memory corruption is still occuring, it's just not occuring to a critical piece of memory such as a return address. You will likely see it re-appear later as you continue modifying the code"
>>>
>>>I'll bet Marc's problem stems from the use of a COM object ( I could lose but the odds are in my favour)

If things have the tendency to go your way, do not worry. It won't last. Jules Renard.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform