code breaks when executing - for no apparant reason

[Libre]

Sometimes when I'm running a vba procedure in Access, the code breakes and throws me into the class module where the code is, and highlites a line in yellow. It acts just as though I put a breakpoint on the line (but there is none). This ususally happens after I've been debugging and maybe HAD one or more breakpoints in the module - except that I removed them but the code still breaks. Even happens if I do a compile (from the debug menu), close the db, reopen, and compact and repair. Even after all this, the code might break. Eventually - after a few more compact and repair operations, it stops. But it is vexing and inexplicable to me.
This happen to anybody else?
Thanks

 

[DJkarl]

Yup, happens from time to time, try going to debug and press Clear all breakpoint, this usually works for me. If that doesn't work, copy and paste the code onto a new line, then delete the old one.

 

[Libre]

Okay - thanks.
Kind of glad it's not only me.
But isn't that very human-like and very uncomputer-like?
I mean - it got "used to" breaking the code right there?
Kind of like going to your old hang-out after you moved to a new neighborhood? Or like calling your 2nd wife by the name of your ex (done it)?
Not to be too anthropomorphic - but really. Computers aren't supposed to act like confused people.

 

[mdlueck]

It acts just as though I put a breakpoint on the line (but there is none).

You need to go through this process with a BACKUP of your database file...

NT Command Script and Documented Steps to Decompile / Compact / Compile an Access DB
http://www.access-programmers.co.uk...to_Decompile_/_Compact_/_Compile_an_Access_DB

 

[boblarson]

Okay - thanks.
Kind of glad it's not only me.
But isn't that very human-like and very uncomputer-like?
I mean - it got "used to" breaking the code right there?
Kind of like going to your old hang-out after you moved to a new neighborhood? Or like calling your 2nd wife by the name of your ex (done it)?
Not to be too anthropomorphic - but really. Computers aren't supposed to act like confused people.

What happens is the VBA window and the code get slightly off from each other. What can help avoid that is to NEVER change code unless all objects are in design mode and not running normally.

 

[Libre]

What happens is the VBA window and the code get slightly off from each other. What can help avoid that is to NEVER change code unless all objects are in design mode and not running normally.

So bob, in other words, if I have a class module open and I'm changing code, I should have the parent form open in design mode? Correct? This is starting to make sense. I think I was changing the code that way right before this occurred.

mdlueck - thanks for the link.

 

[boblarson]

So bob, in other words, if I have a class module open and I'm changing code, I should have the parent form open in design mode? Correct?

Yes, it should be open in design mode or closed. But should not be running in form view, datasheet view, or continuous view at the time you modify code.

 

[Libre]

Bob
my normal mode of debugging is to put a break point - or break points - in the code. When it breaks and I step through the code, if I notice any error or improvement, I would modify it right then and there. Same thing happens when you're running something and the debug message comes up. You're in the code with the parent form active. Are you saying you need to close the parent form or put it in design mode at that point? Because I think you have to end the procedure, to do that.

 

[boblarson]

Yes, that's what I mean. Sucks to not be able to edit right there but it is a known cause of corruption if you don't.

 

[Libre]

Yikes - that's going to change how I do things.
I've been getting those - let's call them, "phantom" break points forever and never understood why. And of course if a user gets one of those and finds themselves thrown into a debug environment, it might not go too well for you - or your program - depending on what this user does or doesn't do.
As I said - Yikes.
And thanks.

 

[mdlueck]

Yikes - that's going to change how I do things.

Why? Do what you need to do when coding, then run the DB cleanup process I linked to in #4 and that will have your DB back happy again.

Access is certainly not a prissy china doll.

 

[Libre]

Why?

Well, I don't understand exactly what the procedure does, and would rather not install it. I am sure that it does what it is supposed to do, but I'm not all that adventurous or knowledgeable - so I'd rather stick to what I fully understand. And especially when you wrote MAKE SURE YOU DO THIS ON A BACKUP - that is kind of a red flag to me.
That is why.

 

[mdlueck]

Well, I don't understand exactly what the procedure does

It eliminates the file size bloat typical with database systems. My suggested batch file merely drives the built-in MS Access decompile process, and I provided click-by-click instructions.

And especially when you wrote MAKE SURE YOU DO THIS ON A BACKUP - that is kind of a red flag to me.
That is why.

So if I had not warned you to be safe and "first make a backup" you would have gone ahead and tried it? How hard is it to make a backup copy before trying something for the first time.

Backup instructions:
1) Completely exit Access
2) Copy the database file
fin

Ma ei tea...

 

[Libre]

Mike-
well, of course I would make a back up first. I normally would do so anytime I'm going to modify anything. So please allow me to retract the "red flag" comment.
It's just that, I do what your batch file does but I do it manually. And I guess I prefer it that way. I've written functions to do this myself from within the program.