Error message & crashes at the end of the code

[GJP55]

I have a form that populates serveral datagrids and then after further user select from one datagrid, repopulates itself based on a selection of a single row.

This all seems to work fine (hence no code listed) however, right at the end, I get a micrsoft error that kicks me out of the VB project. The error is the type where you have a choice to send it off to Microsoft or not.

I have put a msgbox right at the very end just so I can stop and check that the code works ok and the grid repopulates ok (which it does). I am using ADO to call stored procedures to populate the grids and passing back a parmeter. I drop the connection to the SQL database, should I also be dropping the recordsets perhaps ?

 

[ousoonerjoe]

I would check to make sure all RST are closed.
Set RST to NOTHING.
Close all CMD and CNN.
Set to NOTHING.

and place an ON ERROR RESUME NEXT at the beginning of your shut down. That way if something is already closed or set to nothing, it won't error out.

I can't give more with out more info as to where the error occurs.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[JoeAtWork]

It doesn't sound like a bug in your code, as that would simply result in your code halting at the offending line.
It may be something wrong with your VB install. Are you using any 3rd party components?

It might help if you code post your code anyways.

 

[BobRodes]

There's a good deal of spirited argument about setting object references to nothing. I'm dead against it, personally, unless you're in a situation where you know that the object reference is not going to be released when you want it to be. The idea that VB itself is unreliable about releasing object references that go out of scope doesn't hold water with me at all, however.

<and place an ON ERROR RESUME NEXT at the beginning of your shut down. That way if something is already closed or set to nothing, it won't error out.

I'm afraid I can't agree with this either, OUJoe. IMO, this statement should ONLY be used in the context of inline error handling. To use it to simply prevent errors from being thrown begs the question of why the error was thrown in the first place, and such a thing should be known and handled. An unhandled error is by definition a defect, and this technique is to my mind a means of sweeping defects under the carpet.

 

[HughLerwill]

>This all seems to work fine...

Seems it does not? How are you quitting the app?

 

[HughLerwill]

Or what does the code look like leading up to and right at the end.

 

[ousoonerjoe]

Bob in a case of "Clean Up before application ends", I always make sure all forms are closed, objects set to nothing, connections are closed. I do not trust VB's garbage handling completely. This is an example of how I close out an app with no forms. Yes, it's not the prettiest, but it gets the job done.

Public Sub Main()
' various calls and program functions.
'...

'application has completed task and now is shutting down.
    On Error Resume Next
    If Rst.State <> adStateClosed Then Rst.Close
    If Cnn.State <> adStateClosed Then Cnn.Close
    Set ApForm = Nothing
    Set ErrorLog = Nothing
    Set DataFile = Nothing
    Set PgP = Nothing
    Set Rst = Nothing
    Set Cnn = Nothing
    Set Fso = Nothing
    Err.Clear
End Sub

At the end of an application I will double check my connections and objects and make sure they are closed/destroyed. I have always been told it was sloppy programming to leave connections and objects (forms, classes, etc) hanging in memory if they weren't being used. Load them only when necessary and destroy them as soon as you're finished with them. The less you have active in memory, the better/faster your application will run. Nobody likes a program that eats up resources. Users refer to that as "my PC is slow."

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[HughLerwill]

Why are you doing the;

On Error Resume Next

What happens without it? Does an error occurr and if so on what line?

 

[ousoonerjoe]

Sometimes the Rst and Cnn are already set to nothing. Checking to see if they are closed, causes an error. Almost any error at that point in the program is nominal. Skip 'm and drop out.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[HughLerwill]

>Checking to see if they are closed, causes an error

If an Error occurs you should be absolutely sure that the expected error is in fact happening in those two lines and do an

On error Goto 0

after them, and loose the Err.Clear

If this does not help and others here have no ideas I suggest a little more of your code will be required.

 

[ousoonerjoe]

It's not something i'm going to worry about.

I'm not the OP here, GJP55 is.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[HughLerwill]

>I'm not the OP here

Oh dear, sorry ousoonerjoe.

 

[ousoonerjoe]

No problem.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[BobRodes]

<I always make sure all forms are closed, objects set to nothing, connections are closed. I do not trust VB's garbage handling completely.

Although I don't trust it completely either, I don't see where this represents a solution. It's not as if you're using some sort of object releasing routine written in something like C++ or Assembler. "Set x = Nothing" is VB! So what you're saying is that the VB developers might have missed doing the equivalent of "Set x = Nothing" every now and then when an End [Sub, Function, Property] is found. I don't buy it. It seems to me that you are far more likely to miss an object here and there than they are.

As far as I'm concerned, setting an object reference to nothing is done to free up its memory when it is no longer needed and not going to go out of scope any time soon.

<Sometimes the Rst and Cnn are already set to nothing.
Well, if they're already set to nothing, why are you ever referencing them in the code? To me, this leads to disorganized code that is difficult to maintain, hence higher TCO.

Ok, I feel strongly about this, and that doesn't mean I'm right. But I think I am!! I guess everyone has to decide for themselves. For an interesting and livelo discussion of this topic, check

http://www.tek-tips.com/viewthread.cfm?qid=1426535&page=10.

Bob

 

[ousoonerjoe]

I followed that conversation, and I still set to nothing when I'm done with an object. I don't think either of us is right, nor do i think we're wrong. I file this under "style." My style is clearing objects and re-using variables when able. I avoid Variants when able. I consider it good practice to keep your memory usage low when able. Working with C++ programmers like i have they tend to help promote that mentality. "If you're not using it, why keep it there?" VB can be a very sloppy language if you let it. I prefer to get an object out of memory when not in use. This is where we can agree to disagree. I do not want to turn someone else's topic into a sounding board.

"If I were to wake up with my head sewn to the carpet, I wouldn't be more surprised than I am right now.

 

[BobRodes]

Well, I don't find that any of the facts that you have put forth support your position. Bringing up avoiding variants is a "straw man"; we all do the same and it's beside the point. Setting an object to nothing as you do in the above code doesn't "get an object out of memory when it's not in use." It merely duplicates, in a less efficient way, the activity of the End Sub statement immediately following. As such, it's a waste of processor cycles. This is clearly explained in the other thread.

Anyway, there is clearly a good deal of debate about this subject. The other side is, of course, wrong, as I have clearly demonstrated. Seriously, GJP55, make up your own mind on the matter. Don't take either side as gospel.

 

[JoeAtWork]

As I mentioned in my first post, it doesn't sound like a bug in his code, it sounds like a problem with his VB IDE, or maybe his system in general. I would still like to see the OP's code just in case though.

Regarding the references sub-theme, ever since I read StrongM's explanations I have tried to resist the urge to set my recordsets to nothing in local procedures. It's hard to quit a 10 year habit though.