Andreas:
Hi. I have a little more info on the problem...
The stall appears to happen on DBDSQL_PREPARE(). There are 3 arguments
which are a pointer to a status variable, the SQL statement, and the
name of the statement, e.g. STM_1, STM_2, etc.
I placed a couple of fprintf statements to the log file around this
call, and it definitely did not return from the call.
The problem occurs *only* when a valid SQL statement is passed in --
if I specify an SQL statement with a syntax error, it does not hang.
Another interesting point... If I run this in the PTKDB debugger, I
noticed the following behavior:
1) If I just "Run" as the first step, it also hangs in the same way.
2) If I do a "Run To" or set a breakpoint on any statement before the
prepare() call, then run and continue, it works.
Something tells me there is some sort of socket-level communication
breakdown going on here... I'm not familiar with what sort of event
handlers and select() calls the Perl/Tk debugger does. I tried
comparing the %SIG hash between the version running in PTKDB and not,
and there are no differences. However, there must be some difference
in the way the program listens on sockets between the the debugger and
the normal command line.
In any event, do you have any idea what might be going on? Is there
any other test or information I could provide?
Regards,
David Hansen
UBS Warburg Switzerland
______________________________ Reply Separator _________________________________
Subject: Re: DBD::RDB strangeness
Author: andreas.stiller ([EMAIL PROTECTED]) at unix,mime
Date: 06/03/01 02:02
Hi,
sorry, right now i have no idea for this problem. I would try a
rebuild/relink anyway. All machines i can use use currently RDB 7.0-5. But I
found the 7.0.6 on the OTN and will try to investigate this on a
test-machine. Can you doublecheck if the LEF is a RDB-stall in this special
situation ?
Thanks
Andreas
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Gesendet am: Montag, 5. März 2001 19:13
> An: [EMAIL PROTECTED]
> Betreff: DBD::RDB strangeness
>
> Hi,
>
>
> Just a follow up on this problem, here is the result of
> a trace level
> 5 log. Everything looks fine until whe hit the "prepare"
> statement.
>
>
> -> prepare for DBD::RDB::db
> (DBI::db=HASH(0x2e56f4)~0x2e56b8 'SELECT DEALNR,
> DEALSEQNR FROM DEAL WHERE CPTYMNEMONIC = ?')
>
> dbih_setup_handle(DBI::st=HASH(0x2e56e8)=>DBI::st=HASH(0x28b04 20
> 8), DBD::RDB::
> st, 2e56dc, Null!)
> dbih_make_com(DBI::db=HASH(0x2e56b8), DBD::RDB::st, 168)
> dbih_setup_attrib(DBI::st=HASH(0x28b048), Err,
> DBI::db=HASH(0x2e56b8)) SCALA
> R(0x2def5c) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x28b048), State,
> DBI::db=HASH(0x2e56b8)) SCA
> LAR(0x2df04c) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x28b048), Errstr,
> DBI::db=HASH(0x2e56b8)) SC
> ALAR(0x2dee54) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x28b048), Handlers,
> DBI::db=HASH(0x2e56b8))
> ARRAY(0x2e6694) (already defined)
> dbih_setup_attrib(DBI::st=HASH(0x28b048), Debug,
> DBI::db=HASH(0x2e56b8)) 0 (
> already defined)
>
> Regards,
>
> David Hansen
>
> ______________________________ Forward Header
> __________________________________
> Subject: DBD::RDB strangeness
> Author: David Hansen at ch,a,chicago,FX
> Date: 05/03/01 07:44
>
>
> Hello,
>
> I have been using DBD::RDB for a while now without any
> problems. This was on VMS
> 7.2, with RDB v7.0.3-1.
>
> We have a new machine with VMS 7.2 and RDB v7.0.6, which I
> want to use this
> package on.
>
> I tried just copying all the important files related to the
> DBD package to the
> appropriate directories on that machine. When I now run the
> exact same perl
> script on the new machine, it seems to go to sleep in the
> DBD::RDB::st::_prepare() statement and never return. When I
> look at that
> process, its state is LEF (Local Event Flag).
>
> Strangely enough, if I step through this program using the
> Perl/TK debugger
> "ptkdb", and I run to that statement and then do a "step
> over", it works. Once I
> do this once, I can run the program to completion without a problem!
>
> Is there a version issue here which forces me to rebuild
> DBD::RDB with the newer
> version of RDB? Technically the 2 versions of RDB are supposed to be
> backwards-compatible, but that may be at an API and not binary level.
>
> Regards,
>
> David Hansen
> UBS Warburg Switzerland
>
>
>
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
