Brian:
Of course, it'd be nice if the dbms would log happenings within its own
environment, like a UniData BASIC runtime log. It's a pain for regular
folk to have to build such basic functionality within the dbms (or step
through such hoops to get this basic information). :-)
Bill
Brian Leach wrote on 12/5/2008 12:55 AM:
These are all good approaches, but the difficulty is often in trying
to collate the information on what is happening client side and server
side: that usually means poring through multiple log files, especially
if you use different client languages as we did in my last company.
Our approach was to build a global logging client that would display
logging messages from client and server in the same window (colour
coded to make it easier). That way we could watch what was going on in
real time when simulating events, rather than having to wait to close
down the programs successfully and then go through the logs afterwards.
The client components used COM to broadcast to the logger and the
server components used sockets. In that way they would just check to
see if the logger was running when they started up and begin to log if
it was, or bypass the logging if not (there's some magic number
handling as well to ensure it is a legitimate client!). No switches to
turn on and forget to turn off again.
I'll try to get an article on it for the next edition of Spectrum,
deadlines permitting.
Brian
----- Original Message ----- From: "Hona, David S" <[EMAIL PROTECTED]>
To: <u2-users@listserver.u2ug.org>
Sent: Friday, December 05, 2008 5:02 AM
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Note that the SYSTEM(9001) function call returns the runtime stack.
I use a generic logging subroutine that writes to a sequential file any
information I want to log:
call @debuglogger("Starting phase 1")
In debuglogger, it writes out timedate stamp, PID, @USERNO, @WHO, @PATH,
etc., etc. along with the desired message. We have a global common flag
to toggle it on/off or output to screen, as well.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Reynolds
Sent: Friday, 5 December 2008 1:23 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Interesting idea that.
As standard, all subroutine calls in our software add to a "Stack" and
their names are deleted from the stack when control is returned to the
calling level. It doesn't solve the debug issue, but has given me an
idea about tracing. I'm sure the code was originally designed for such a
purpose, it was just never implemented.
Dave
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R.
Sent: 04 December 2008 13:31
To: 'u2-users@listserver.u2ug.org'
Subject: RE: [U2] DEBUG mode on a UniObjects connections
Just chiming in on the debugging in a web page which might also help
here since you loose the ability to interact.
I have written a universal E-mailing program that can be called from any
UniData program. It will work with both simple text or HTML depending
on how much effort the programmer wants to exert.
There are several simple INCLUDES that store COMMON info so that I can
just plug this into any subroutine I want.
Starting with my top-most subroutine (the one called by Redback), I
INCLUDE my setup code and set a COMMON flag as either null (disable
debugging E-mail) or with the name of the ASP web page (enabling the
debugging E-mail).
At critical points, I test if the E-mailing flag is turned on, and if
so, create an E-mail with all the critical info I might want at that
point, then send the E-mail to myself. This E-mail includes the
initiating web page and all subroutines that have been called to get to
the current subroutine.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/