Why does Access break on cancelled break points?
Sometimes MS Access begins to pause the process (break) on a break point that had been once set and later cancelled. It now happened on the client workstation after deployment of a big application.
What's the best way to prevent or at least get rid of this kind of errors? (Please answer only if you understand what I am talking about. Do not "Try this or that...", because it was already tried. I am asking about the best way from an expert who had suffered this. Also do not reply if you need OS / Access / Computer versions / brand for your answer, because it does not depend on them.)
What's the best way to prevent or at least get rid of this kind of errors? (Please answer only if you understand what I am talking about. Do not "Try this or that...", because it was already tried. I am asking about the best way from an expert who had suffered this. Also do not reply if you need OS / Access / Computer versions / brand for your answer, because it does not depend on them.)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>>by: mbizupPosted on 2013-07-09 at 12:00:31ID: 39311166
MS does not subscribe to this point of view: "Edit and Continue is a time-saving feature that enables you to make changes to your source code while your program is in break mode."
MS does not subscribe to this point of view: "Edit and Continue is a time-saving feature that enables you to make changes to your source code while your program is in break mode."
midfde:
That really does not matter, because this has been shown/known to cause this issue. Period.
If all else fails, please reboot your system.
mx
That really does not matter, because this has been shown/known to cause this issue. Period.
If all else fails, please reboot your system.
mx
midfde,
The link you posted pertains to Visual Studio 2012, not MS Access.
The link you posted pertains to Visual Studio 2012, not MS Access.
ASKER
Dear mbizup, I was talking about your:"...not to change it while running" vs. their (and my for that matter): "...a time-saving feature that enables you to make changes... while your program is in break mode."
Be it in MSVS (not always available) or MS Access (always available, but buggy).
Be it in MSVS (not always available) or MS Access (always available, but buggy).
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
midfde,
I understood what you meant. Visual Studio (which your link refers to) is a much more stable development platform than Access is.
Regarding Access, I realize that this is not an official Microsoft link, but Allen Browne is a well respected long time Microsoft MVP who understands very well how Access behaves from a developer's standpoint -- likely even more familiar with that than the MS Access product development team. So certainly more credible than I am. Take a look at his fifth point here under "Preventing Corruption During Development":
http://allenbrowne.com/ser-25.html
I understood what you meant. Visual Studio (which your link refers to) is a much more stable development platform than Access is.
Regarding Access, I realize that this is not an official Microsoft link, but Allen Browne is a well respected long time Microsoft MVP who understands very well how Access behaves from a developer's standpoint -- likely even more familiar with that than the MS Access product development team. So certainly more credible than I am. Take a look at his fifth point here under "Preventing Corruption During Development":
http://allenbrowne.com/ser-25.html
Not sure I'd agree with that. I often make code changes on the fly and I don't see corruption.
But I should point out that I always stop if I get prompted that I won't be able to save the project, so the number of changes you can make to code at runtime is actually very small.
Jim.
But I should point out that I always stop if I get prompted that I won't be able to save the project, so the number of changes you can make to code at runtime is actually very small.
Jim.
ASKER
>>Not sure I'd agree with that.
Neither am I. I also believe MS Access resists only if the change requested makes re-compilation process dubious.
Neither am I. I also believe MS Access resists only if the change requested makes re-compilation process dubious.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
My rule: generate from Version Control, and then deploy. I know, I know, me better follow it. Always.
In terms of prevention, possible causes include modifying code while your objects are not in design view (for example editing code when in Form view, or editing code in debug mode - ie: without stopping/resetting your code. Breakpoints should be used to help understand the flow of a program, but not to change it while running.)