• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 297
  • Last Modified:

Why does Stop not stop

I often get the condition where a Stop line of code gets ignored.  The only solution I have found is to create a new database and import everything into it.

Does anyone know why this happens and if there is anything I can do to prevent it?

Thanks in advance.
0
CRB1609
Asked:
CRB1609
1 Solution
 
ChloesDadCommented:
The obvious answer is that the line is not being executed, and hence the breakpoint never happens.

Alternatively, if you are running in Release mode then breakpoints are ignored.
0
 
CRB1609Author Commented:
1. The immediate preceding and subsequent lines are being executed.

2. I'm running a normal accdb.
0
 
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareCommented:
CRB1609: You included the .NET zone here. Are you using VB.NET for this, or is this all contained in Access? I believe the comment from ChloesDad is intended for the .NET languages, which have a Debug and Release mode ...

==============================

Assuming this is an all-Access project, then issues like this are a sign of corruption in the database, and moving to a new container as you're doing now is the only real "fix" for it.

Corruption happens for many reasons, but to reduce the chances:

-- Never modify code in break mode. Never.

-- Split the database into a Backend (tables only) and a Frontend (everything else). The chances for corruption are much greater for forms/reports, etc than for tables.

-- Turn OFF Name AutoCorrect. You don't need it. You really don't.

-- Compile your code frequently. To do that, from the VBA Editor window click Debug - Compile, fix any errors, and continue doing this until the Compile option is disabled. When you make code changes, you'll have to compile again.

-- Don't use 3rd party controls or libraries unless they are compliant with Access (and there are very, very few of those). Just because "it works" doesn't mean it works. This includes ALL Microsoft Controls as well (none of them are "compliant" with Access 2010).

-- Compact your database frequently. In 2010 the Compact option is right on the main backstage menu, so get in the habit of doing this frequently.

-- Never work on a live database.

-- Decompile your code occasionally. This helps to clean up the PCode contained in Access, which can get out of whack occasionally. To Decompile, build a shortcut with a Target like this:

  "Full path to msaccess.exe" "full path to your db" /decompile.

Run that shortcut, then compile and compact

-- Always work on LOCAL copies of the database. Never try to open a remotely hosted database across the LAN - even on local networks. Move the file to your machine and do the work there.

-- Make backups frequently. This doesn't help to reduce corruption, but it puts your mind at ease.

-- Make sure your Office system is fully up to date in regard to service packs, updates, etc. Same goes for Windows.
0
 
pdebaetsCommented:
If you are executing in runtime mode, the Stop statement will not execute.
0
 
CRB1609Author Commented:
Very helpful.  Doing some of it but the other stuff is great.  

Thanks very much.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now