When is Debug.Print executed?

Is it true that Debug.Print is always executed in mdb files, but never executed in mde files?
LVL 1
MilewskpAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Yes/No

You would never see the results in an MDE because you cannot open a code window - specifically the Immediate Window .  AFAIK, it technically still prints.

It's always executed in an MDB.  Whether you see the results or not depends on if you have the VBA Immediate Window open when your code runs that executes the Debug.Print, although the results will remain in the Immediate Window ... until replaced by another Debug.Print.

mx
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"AFAIK, it technically still prints."
Then again, maybe the MDE inhibits that for efficiency sake.  I've never seen that specified one way or another.  And really, I can't see that it matters, since it's a "no-op"

mx
0
Jeffrey CoachmanMIS LiasonCommented:
Remember, you use your "Golden" copy of the MDB to view and Debug data anyway.

The MDE is the just the end user distributed front end, ...that is based on the MDB file.

FWIW, Since you can only view the Imm. Window in the VBE, ...This is why I tend to use messagesBoxes to debug in some cases.
Then at least I can concatenate strings and make human readable debugging messages:

msgbox "Combobox77 Column 3 has a value of: " & me.combo77.Column(3)
Or
msgbox "The Customer Name is: " & me.CustName & vbcrlf & "...and the shipping cost is: " & me.ShippingCost
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"Then at least I can concatenate strings and make human readable debugging messages::
Well, you can also do that with Debug.Print ...

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

  Interesting question...I have not seen it defined either one way or another.

  But I don't think it's a no-op.  A MDE is nothing more then a MDB with the source code stripped out, so it's going to execute the same.

  As a little test, put a debug statement inside a loop for 100,000 interations with start/stop times recorded in a procedure and use a msgbox at the end of the procedure to display the times.   Try that in a MDB with the VBA window closed and open.  Then try in the MDE.   If I'm not mistaken, I think you'll find that it does execute under all cirumstances.

  Then try in the run-time as well.  There, you might see a no-op, but I think it will execute even there.

 I'd do it, but I'll be out all next week and have a bunch of stuff I need to get cleared out before I leave.

JimD.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"But I don't think it's a no-op"
I meant ... It's not going to do or hurt anything, so I really don't care if it executes.

mx
0
MilewskpAuthor Commented:
Hi Jim,
I thought I read a paper on debugging by Luke Chung (maybe on his FMS website) that said that debug.print is not always executed, so it's Ok to leave it in. But I can't remember the circumstances under which it doesn't execute, and couldn't find the paper (which was really good btw).

I like your idea, I'll try it myself if I have time, but things have been crazy busy at work the last two weeks.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
From here:

http://www.fmsinc.com/tpapers/vbacode/debug.asp#DebubbingGoals

"Disable or Eliminate Debugging Code

Before delivering your application, make sure your debugging code is removed or disabled. Code such as Stop; Debug.Print; Debug.Assert; should be eliminated or put into sections that won’t be invoked."

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

 Well it's your fault I'm gonna be late with some stuff; curiosty got the better of me. LOL.  I just love your questions.  You come up with some hum-dingers.

Answer:

  Doesn't matter if it's a MDB or MDE, it still executes.  It does not however execute under Runtime mode.

JimD.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
@ http:#a35353313  :-)

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<@ http:#a35353313  :-)>>

  Which is incorrect as is the follow on comment you made.   You can open the VBA editor and the debug window in a MDE.  

And with your other comments:

<<Then again, maybe the MDE inhibits that for efficiency sake.  I've never seen that specified one way or another.  And really, I can't see that it matters, since it's a "no-op">>

 and

<<I meant ... It's not going to do or hurt anything, so I really don't care if it executes.>>

  Implies that you really didn't know (and don't care as you stated).

  However I think the point of the question is; is it a performance hit in a MDE?  The answer is yes with the full version, no in run-time mode be it a MDE or MDB.

JimD.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"You can open the VBA editor and the debug window in a MDE.  
Yep, you're right.

"is it a performance hit in a MDE?"
Then it's just as much a performance hit in an MDB.

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<Then it's just as much a performance hit in an MDB.>>

 Yes, unless your in run-time mode, and then it's not with either format.

JimD.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
I didn't notice 'runtime' as part of this question ... nor did I see the Q had anything to do with performance, so I guess you are just a visionary ...

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

  42, 16, 23 15, ....

JimD.
0
MilewskpAuthor Commented:
Folks,
I ran this procedure via a macro:
Public Function TEST()
   Dim i As Long
   Dim StartTime As Double
   
   StartTime = Timer()
   
   For i = 1 To 10000
      Debug.Print "@"
   Next i
   
   MsgBox Timer - StartTime

End Function

Open in new window


under the follwoing conditions:

- MDE File:                                                0.15 sec
- MDB File, VBE window never opened:   0.15 sec
- MDB File, VBE window open, or closed now but was opened since MDB was opened:   3.95 sec
- MBD File, VBE Immediate window open: 12 sec

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
Not what I got.  Didn't matter if it was a MDB or MDE.  Only difference was runtime vs full retail version.

I used a very similar test.  I'm traveling at the moment and don't have it with me, but will post it tomorrow when I get back into the office.

JimD.
0
MilewskpAuthor Commented:
Hi Jim,
<Didn't matter if it was a MDB or MDE. >
Same here, as long as the VBE window hadn't been opened since the MDB was opened.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
What about with the MDE and VBE window open?  I don't see that test ...?

mx
0
MilewskpAuthor Commented:
<What about with the MDE and VBE window open?>
Is that possible?
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
As JDettman pointed out @ http:#a35354217 ... yes, and I did confirm that.

mx
0
MilewskpAuthor Commented:
Hi mx,
How do you open the VBE window in an MDE database?
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Control+G opens the Immediate Window.  So, if you open the database, then hit Control+G ... the Immediate window (only) opens. In an MDB, both the VBE and Immediate Windows open.

Since Debug.Print only displays in the Immediate Window, that's what we are concerned with here.

mx
0
MilewskpAuthor Commented:
Hi mx,
I didn't know that. Thanks!

Results:
- MBE File, VBE Immediate window open: 12 sec
- MBE File, VBE Immediate window closed, but was opened since MDE was opened: 0.75 sec




0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Well, I suspect that when Access does actually have to Print to the screen (Immediate window) ... that IS going to take longer than just 'going through the motions', ie ... executing the Debug.Print command w/o actually shoving text to the screen.

mx
0
MilewskpAuthor Commented:
Side Note:
I've recently added the following to the start of almost all of my procedures (including event procedures):

    Debug.Print "@" & conThisModuleName & "." & conThisProcName

I then use the Immediate window during debugging to track down bugs. This is especially helpful when dealing with event procedures.

It that what the experts use?
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"It that what the experts use?"
Not me.  

Get the free MZTools (http://www.mztools.com/v3/mztools3.aspx ).  Besides being able to add  line numbers to your code, then use the ERL function in your error handling to show the Line Number, you can have MZTools - via a Template you create, automatically insert all of the relevant information (Module Name, Procedure Name and MORE) ... at the top of the procedure or anywhere you like.  And, you can easily create custom error handling templates, which use this information.

mx
0
MilewskpAuthor Commented:
Hi mx,
I have mx tools (they are great!), but the line numbers only tell you where the error occurred, not the sequence of procedure calls that got you there. My approach simulates the calling stack.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"My approach simulates the calling stack."
I suppose, but I don't have those kinds of issues. Also this ... the Ultimate Global Error Handler ... gives you all of that information:

http://www.everythingaccess.com/vbwatchdog.htm

BUT ... certainly nothing wrong with your approach ...

mx
0
MilewskpAuthor Commented:
Hi mx,
<Ultimate Global Error Handler>
One of these days I'll have to get that. Thanks for reminding me.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
It's VERY cool.  All of my new apps are incorporating that now.  And at some point, I will retrofit others.

mx
0
MilewskpAuthor Commented:
Ah yes, the dreaded retrofit.... ;)
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Well, it's not something that I have ... to do, but rather want to do ... to eliminate and consolidate a bunch of error handling code ...

mx
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
FWIW,  Here's the test I did:

Private Sub Command0_Click()

  Dim dtStart As Date
  Dim dtEnd As Date
 
  Dim lngK As Long
 
  MsgBox "Ready to start", vbInformation + vbOKOnly
 
  dtStart = Now()
  For lngK = 1 To 100000
    Debug.Print "Jim Dettman"
  Next lngK
  dtEnd = Now()
 
  MsgBox "Start time: " & dtStart & "   End time: " & dtEnd & "   Difference: " & DateDiff("s", dtStart, dtEnd), vbInformation + vbOKOnly
 
End Sub

  I'm still trying to catch up from being gone, so I have't re-tested as yet.
 
 And in regards to debugging, I do the same (line #'s and VBA.ERL).  Here's my error handler call:

AppAlreadyUp_Error:
350     UnexpectedError ModuleName, RoutineName, Version, Err.Number, Err.Description, Err.Source, VBA.Erl
360     Resume AppAlreadyUp_Exit

  ModuleName, RountineName, and Version are constants I stuff in the module and procedures.  I don't worry about the call stack as I'm never more then a couple of procedures deep.

JimD.

0
MilewskpAuthor Commented:
Hi Jim,
Interesting. I call my error handler UnexpectedError() too, but I've often wondered if I should change name, for two opposing reasons:
1. It goes without saying that errrors are unexpected, so why say it?
2. If you expect the UnexpectedError() to handle errors, doesn't that make them expected errors, hence shouldn't it be called ExpectedError()?
-   ;)
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
"It goes without saying that errrors are unexpected,"

Actually it doesn't.  Many errors are expected - you know they could occur, and you specifically trap those errors and handle them accordingly. One example right off are the Write Conflict errors that *can* occur in a multi-user system.  So, you set up separate traps for those two error numbers, maybe display a friendly message to the user, and so on.  It's all the errors that you cannot foresee that are 'unexpected'.

I see no need to use either word in naming the error handler.

mx

0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
Example ...
Capture1.gif
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<It's all the errors that you cannot foresee that are 'unexpected'.>>

  Exactly.

  I should mention to that one of the neat things I do (but not unique I'm sure) is that besides messaging the user and logging the error to a table, I have the app e-mail an admin or myself with the error.

  It's amazing the reaction you get when you call someone up and ask "What were you just doing when you got that error a minute ago?".   Really creeps some people out<g>.

JimD.
0
DatabaseMX (Joe Anderson - Microsoft Access MVP)Database Architect / Systems AnalystCommented:
0
MilewskpAuthor Commented:
Hi Jim,
<I have the app e-mail an admin or myself with the error.>
Me too, and I've also surprised some users.

What frustrates me is that knowing the module, procedure and line on which the error occurred is not enough. Unless the user can reproduce the error for me, I really need to know the keystrokes that the user used and the state of the data at the time of the error.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<What frustrates me is that knowing the module, procedure and line on which the error occurred is not enough. Unless the user can reproduce the error for me, I really need to know the keystrokes that the user used and the state of the data at the time of the error. >>

  That's one of the reasons I added the e-mail.  I like to call them right away as in some cases, I need to know what steps they did leading up to the error.  Generally, I don't see errors any more unless it's something pretty weird.

  But even with that said, I've found over the years that numbering the lines and having a error handler like I posted has gone a long way in reducing the amount of time I spend debugging.

JimD.
0
MilewskpAuthor Commented:
Hi Jim,
<I like to call them right away as in some cases, I need to know what steps they did leading up to the error.  Generally, I don't see errors any more unless it's something pretty weird.>
Good to know - I'll try that. Thanks.
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

 Let's not delete this please; lot's of good stuff here.  Post a comment and then accept that as the answer so this makes it into the PAQ please.

JimD.
0
MilewskpAuthor Commented:
Hi Jim,
It wasn't my intention to delete this. I just accepted my post as the solution.

Can you send me a screen shot of where it says that I'm trying to delete this? Nothing shows up on my screen (it's as if I never accepted a solution; EE glitch?)
0
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:

  No, my mistake; thought the e-mail said it would be deleted in 4 days.  It did say it would be closed (the messages look quite similar).

  Sorry to make you have to do it again.

JimD.
0
MilewskpAuthor Commented:
.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.