I use a fair number of debug.print statements. My apps are
fairly well 'peppered' with them. I've often wondered if leaving
them in the mdb, creating and rolling out an mde intended for
use in the A97 runtime environment might ever be cause for
concern. I've noticed no symptoms to indicate a problem. Are
there drawbacks to this practice?
Tim Marshall - 13 Dec 2005 19:59 GMT
> I use a fair number of debug.print statements. My apps are
> fairly well 'peppered' with them. I've often wondered if leaving
> them in the mdb, creating and rolling out an mde intended for
> use in the A97 runtime environment might ever be cause for
> concern. I've noticed no symptoms to indicate a problem. Are
> there drawbacks to this practice?
I asked a similar uestion a while ago and I believe the consensus was no
real effects. However, for development, the debug window is a valuable
tool and I prefer to turn these off as much as I can so as not to have
too cluttered a debug screen when I need it. A simple mdb wide find and
replace debug.print wit 'debug.print suffices, though you'll end up with
a number of '''''''''debu.prints. No matter, when you need it for
development purposes, you can remove the comment character.

Signature
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
David W. Fenton - 13 Dec 2005 20:17 GMT
> I use a fair number of debug.print statements. My apps are
> fairly well 'peppered' with them. I've often wondered if leaving
> them in the mdb, creating and rolling out an mde intended for
> use in the A97 runtime environment might ever be cause for
> concern. I've noticed no symptoms to indicate a problem. Are
> there drawbacks to this practice?
It could conceivably be a minor performance drain, but otherwise not
a big deal.
If you care about this kind of thing, you could create a subroutine
to call Debug.Print that checks if you're running in the runtime. I
don't know the actual command for that, but I know it exists. Your
function would take a string argument and could be something like
this:
Public Sub PrintDebug(strOutput As String)
' check for runtime however it's done
If [is runtime] Then Exit Sub
Debug.Print strOutput
End Sub
Then you could do a search and replaces on all your "Debug.Print"
statements with "PrintDebug" (except, of course, the one in the
PrintDebug() subroutine).

Signature
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Br@dley - 13 Dec 2005 20:48 GMT
>> I use a fair number of debug.print statements. My apps are
>> fairly well 'peppered' with them. I've often wondered if leaving
[quoted text clipped - 21 lines]
> statements with "PrintDebug" (except, of course, the one in the
> PrintDebug() subroutine).
Another solution may be to check the current user (either Windows or
Workgroup) and conditionally run the code.
eg.
Function MyDebug(pObject as String, pValue as Variant)
If CurrentUser()="developer" Then
Debug.Print pObject & " = " & pValue
End If
End If
Or another may be to check for a command-line argument (ie. you'd call
your app up using a shortcut with a specific arguement)
eg.
Shortcut:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\BIGCare\BigCare.mde" /wrkgrp "C:\BIGCare\Data\BigCare.mdw" /cmd
"developer"
Function MyDebug(pObject as String, pValue as Variant)
If Command()="developer" Then
Debug.Print pObject & " = " & pValue
End If
End If

Signature
regards,
Bradley
A Christian Response
http://www.pastornet.net.au/response
David W. Fenton - 13 Dec 2005 20:20 GMT
> I use a fair number of debug.print statements. My apps are
> fairly well 'peppered' with them. I've often wondered if leaving
> them in the mdb, creating and rolling out an mde intended for
> use in the A97 runtime environment might ever be cause for
> concern. I've noticed no symptoms to indicate a problem. Are
> there drawbacks to this practice?
Oh, one thing I meant to include in my post about creating a
subroutine to do Debug.Print statements:
Don't check for the runtime every time. Instead, use a static
variable and check that it's been initialized and look it up only if
it hasn't been. That means you can't use a Boolean variable.
Static intIsRuntime As Integer
If intIsRuntime = 0 Then
If [isruntime] Then
intIsRuntime = -1
Else
intIsRuntime = 2
End If
End If
Then you'd check to see if intIsRuntime = -1 before printing your
debug statements.

Signature
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Darryl Kerkeslager - 14 Dec 2005 01:35 GMT
I've taken to using this solution for combined debugging and error handling.
In a module:
Public Const BCONN = "Connecting to server"
Public Const BCLOSE = "Closing connection"
Public Const BSAVES = "Saving to server"
Public Const BSAVEL = "Saving locally"
Public Const BUPD = "Updating form"
Public Const BEXES = "Executing on server"
Public Const BEXEL = "Executing on server"
Private errorText As String
'--------------
Public Sub Bug(commentString As String)
errorText = commentString
SysCmd acSysCmdSetStatus, commentString
End Sub
'--------------
Public Sub NoBug()
DoCmd.Hourglass False
errorText = vbNullString
SysCmd acSysCmdClearStatus
End Sub
'--------------
Public Function GetBug() As String
GetBug = errorText
End Function
'--------------
Public Sub LogError(errLoc As String, errDesc As String, Optional messageBox
= True)
On Error GoTo handle_error
' The next two lines are because I want the ID of the offender record, and
' have found the error numbers usually useless
Dim errNo As Long
errNo = Nz(GetOffender_ID(), 0)
If StrComp(GetBug(), BCONN, vbTextCompare) = 0 Then
errDesc = BCONN
Else
errDesc = Left(Left(errDesc, 150) & (" " + GetBug()), 255)
End If
DoCmd.Hourglass True
Dim cnxn As ADODB.Connection
Set cnxn = New ADODB.Connection
With cnxn
SysCmd acSysCmdSetStatus, BCONN
.Provider = "Microsoft.Jet.OLEDB.4.0"
.Open "Data Source=" & GetServer()
SysCmd acSysCmdSetStatus, "Logging error"
.Execute "INSERT INTO db_error_log (err_number, err_location,
err_desc, err_user, err_time)" & _
"VALUES (" & errNo & ", " & S2SQL(errLoc) & ", " & _
S2SQL(errDesc) & ", " & S2SQL(GetUserLogin()) & ", #" &
Now() & "#)"
SysCmd acSysCmdSetStatus, BCLOSE
.Close
End With
DoCmd.Hourglass False
DoCmd.Echo True
SysCmd acSysCmdClearStatus
If messageBox Then
If StrComp(GetBug(), BCONN, vbTextCompare) = 0 Then
MsgBox "The server was busy. Please try the operation again.",
vbOKOnly, "Server Busy"
Else
MsgBox "The following error: [" & errDesc & _
"] was generated from module: " & _
errLoc, vbOKOnly, "Error: " & errNo
End If
End If
Exit Sub
handle_error:
DoCmd.Hourglass False
MsgBox "Unable to write data to the server. " & _
"Errors are not being reported. Please contact " & _
"the system administrator and report this error." & _
"Highest priority.", vbCritical, "Critical Error!"
' Application Quit
End Sub
'-------------------------
In production, the Bug() statement can easily be changed to not echo to the
status bar.
A typical function then has no comments, just Bug() statements:
Private Sub btnSave_Click()
On Error GoTo handle_error
DoCmd.Hourglass True
Dim cnxn As ADODB.Connection
Dim rS As ADODB.Recordset
Set cnxn = New ADODB.Connection
Set rS = New ADODB.Recordset
Bug (BCONN)
cnxn.Provider = "Microsoft.Jet.OLEDB.4.0"
cnxn.Open "Data Source=" & GetServer()
Bug (BSAVES)
With rS
.Source = "SELECT * FROM current_sup WHERE cs_off_id=" & _
Me!txtOffID.Value
.Open , cnxn, adOpenKeyset, adLockOptimistic, adCmdText
.Fields("cs_pda_notes") = Me!txtNotes.Value
.Fields("updated") = Now()
.Fields("update_by") = GetUserLogin()
.Update
.Close
End With
Bug (BCLOSE)
cnxn.Close
Bug ("Updating list")
CurrentProject.Connection.Execute "UPDATE HomeCaseloadTable SET Notes = "
& _
S2SQL(Me!txtNotes.Value) & " WHERE Vaccis=" &
Me!txtOffID.Value, , adCmdText
NoBug
DoCmd.Close acForm, Me.Name
Forms("HomeForm")!lstCaseload.Requery
Exit Sub
handle_error:
LogError "GoCaseloadForm.btnSave", Err.Description
End Sub

Signature
Darryl Kerkeslager