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