Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / December 2005

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
MLH - 13 Dec 2005 18:32 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?
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

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.