Re: Remote sysmaster queries in 9.4
This is a known product bug, #167088. The fix is available in the
latest fixpack 9.40.xC5.
thanx
Prasad
bothwellno@spam.duke.edu wrote in message news:<cmg84p$u9c$1@gargoyle.oit.duke.edu>...
> bothwellno@spam.duke.edu wrote:
> : We have a 4GL program that searches for users causing sequential scans
> : by querying several tables in the sysmaster database.
> : The 4GL program runs on a development server and queries sysmaster
> : on a production (remote) server.
> : We recently upgraded both servers from 7.31 to 9.40.FC2 and
> : AIX 4.3.2 to 5.2.
>
> One correction to this -
> Our development server is at 9.40.FC4W1
> Our production server is at 9.40.FC2
> According to the developers, this query worked fine when both
> servers were at 9.40.FC2.
> Perhaps there is some sysmaster incompatibility between these
> two releases?
>
> : The 4GL program ran fine in the 7.31/4.3.2 environment.
>
> : Here's the query:
>
> : select x3.username, x3.pid, x3.hostname, x1.cbl_seqscan, x1.cbl_stmt
> : from sysmaster@production:syssdblock x0,
> : sysmaster@production:sysconblock x1,
> : sysmaster@production:flags_text x2,
> : sysmaster@production:syssessions x3,
> : sysmaster@production:sysopendb x5
> : where
> : x0.sdb_sessionid = x1.cbl_sessionid and
> : x0.sdb_sdbno = x1.cbl_sdbno and
> : x2.tabname = 'sqltype' and
> : x2.flags = x1.cbl_selflag and
> : x3.sid = x0.sdb_sessionid and
> : x5.odb_sessionid = x0.sdb_sessionid and
> : x1.cbl_stmt matches '*prod_tab_name*' and
> : x1.cbl_seqscan > 0 and
> : x5.odb_dbname = 'prod_db'
>
> : We're connecting to the local development sysmaster database
> : (dbaccess sysmaster@development) using a TCP/IP connection.
>
> : The query terminates with the following error when run in the
> : new environment:
>
> : 674: Routine (bitval) can not be resolved.
>
> : I found I can query any of the tables by themselves. I receive the 674
> : error whenever I try to join another table.
>
> : I have found that the query will run successfully from the development
> : server if we connect directly to the remote (production) sysmaster
> : database (dbaccess sysmaster@production), but this will require some
> : developer's time to modify the 4GL program.
>
> : Can anyone provide a little more insight as to why the query terminates
> : with the 674 error now?
> : Has anyone seen this or know of a work around?
>
> : Thanks.
>
> : Bob
>
> : --
> : bothwellno@spam.duke.edu