Leaving debug.print statements in a database intended for runtime?

[MLH]

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]

MLH wrote:

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.

--
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]

MLH <CR**@NorthState.net> wrote in
news:qn********************************@4ax.com:

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).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:qn********************************@4ax.com:

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.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Br]

David W. Fenton wrote:

MLH <CR**@NorthState.net> wrote in
news:qn********************************@4ax.com:

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).

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

--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

[Darryl Kerkeslager]

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

--
Darryl Kerkeslager