Hi all,
I'm new to the list, and hope that someone may have the answer to a
problem which is causing me a lot of headaches at the moment.
I'm using VB6 and UniObjects to connect to a Universe Database.
I call DataBasic routines from the VB6 client.
All works fine, until there is a problem in
Hi Dave
A uniObjects subroutine call is a 'black box' RPC. It doesn't allow any kind of
user interaction to interrupt the call. If you're going into debug, that will
hang because it has nowhere from which to take input.
Sorry, but that's how it is designed.
Brian
Hi all,
I'm new to the
The U2 User Group Board met via conference call at 4:00p US Eastern time on
Tuesday, September 9, 2008.
Complete minutes have been posted to the forum
In attendance were Laura Hirsh, Brian Leach, Chuck Barouch, Baker Hughes and
Susan Joslyn
Business discussed included:
OLD BUSINESS:
7
Databasic will only go into debug mode if you tell it to - this is done
either at the command line or with a debug statement in the code. Since you
are calling the sub from uniobjects it will not be a command line issue so i
suspect you have a debug statement in the code. You need to find it and
Hi Brian,
Wrong answer(Grin).
If I run the same thing under JBASE, and it drops into DEBUG, everything
is fine, and I can even step through the program a line at a time.
Oh, well, back to the drawing board. I wonder if I could use Process
viewer to see what is happening.
Many thanks for your
The problem is that it goes into DEBUG because of an error in the
routine, not because of a command in the program.
Thanks,
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Symeon Breen
Sent: 04 December 2008 11:56
To: u2-users@listserver.u2ug.org
Brian,
Interestingly, I have just nocked up something using a demo f MVdotnet
which uses Core Connections. This opens a session window when I go into
DEBUG, and I can perform all standard dEBUG commands. The only slight
problem is that all our software is written using UniObjects, and I am
When I have a problem like this I usually put a COMO ON statement near
the top of the program and the look at the output stored in the COMO
file. If you have a bad line of code that causes the abort or debug you
can see what you would normally see on the screen if you were using an
interactive
Agreed with COMO comment. Depending on your version of Universe you may also
be able to:
1. TANDEM to the UniObjects port. This should enable you to interact with the
debugger.
2. See any errors produced by looking at the runtime error log (create a file
called errlog in the uvhome)
In
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
Dave,
Why don't you write a wrapper program that call the same routine that uniobject
calls.
That way you can trace thro what caused the routine to go into debug mode
also debug it.
When your happy with, try the uniobjects call.
Ps. If you are trying to catch exception in the subroutine, you
Brett,
I entirely agree with you, and if humanly possible, I'd rather not go
into DEBUG at all. I even have a test bed for routines, which can be run
in a telnet session, so that by the time you get to the point where you
are calling it from VB, all errors are ironed out. But you know how it
is...
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
Hi All
Does anyone know whether the latest ODBC drivers for UniData will work under
Vista?
Thanks
Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Dave, if you suspect a server-side routine might fall to debug
then I'd recommend putting server access into a separate
client-side thread. That doesn't stop the aborts, but it does
prevent such things from affecting the end-user's session.
Having a lot of experience with the visually-impaired
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
16 matches
Mail list logo
