不详的预感 [英] Sinking Feeling
问题描述
我有一个成功的应用程序，用于各种客户端/服务器
情况。 （DB2 8.x.）
我需要更新它以具有XML功能，以便与几个其他外部程序接口。因此，我很高兴看到DB2使用V9.x执行我需要的工作
我将实验服务器升级到9.5并将客户端升级到相同。我是使用UDB for LUW的
，服务器是Windows Server 2003和客户端
是XP。编程语言已经（到目前为止）VisualBasic 6.
现在，突然，Connection对象需要大约100倍的时间来连接，而Command对象需要从存储过程中收集
参数的时间大约长100倍，并且实际的执行需要大约100倍的时间才能获得记录集并返回SQLSTATE到
命令对象！
此外，当应用程序对SP的调用无法在SP找不到时，有许多不可预测的情况所有并返回一个致命的错误！
我有一个令人厌倦的感觉IBM已经强制要求更多Java - 更慢，
笨重，容易出错的Java。请有人告诉我，这不是
所以。
或者告诉我它是这样，所以我可以做我必须做的事情。 。 。
28 ****** @ gmail.com 写道：
我有一种令人不安的感觉IBM已经强制要求更多Java - 更慢，
笨重，容易出错的Java。请有人告诉我，这不是
所以。
或者告诉我它是这样，所以我可以做我必须做的事情。 。 。
服务器上没有Java。不管它是什么，都不是。
你的症状是通用的（更像是疼痛的腹部;-)给出声音
的建议。你能打开PMR吗？
或者我建议分而治之。
从CLP连接。运行一些测试。
如果连接是本地的，会发生什么？等等...
干杯
Serge
-
Serge Rielau
DB2解决方案开发
IBM多伦多实验室
Serge，
I并没有考虑服务器上的Java，而是考虑新的客户端。在这一切期间，有一些b $ b似乎是一些磁盘颠簸（正如我所说的那样，需要花费很多时间，比之前的连接要长得多。
1.本地连接没问题，即如果客户端和服务器在同一个盒子上，
执行存储过程并正确返回。
2。远程CLP连接很好。
3.从远程客户端执行的直接SQL语句很好。
那么，
4.存储的调用从新客户端（9.5 LUW）到
新9.5服务器的程序失败。这是发生的事情:(每个都是代码中的一步
客户端:)
a）客户端Connection对象（通过新的ODBC，我认为它在
MDAC 2.8中）与服务器的连接速度很慢，用磁盘
thrashing。
b）使用Command对象联系SP并拿起号码和
类型的参数（IN，OUT）通过准备命令在代码中。
（此时显然可以阅读SP。）
c）回到客户端，Command对象加载了值
$ b IN参数的$ b。
d）这将返回服务器，以便SP中的SQL运行。
e）此时a关于执行（成功） ）"事件发生在
Connection对象中，其Satus为1（成功）。
Finis。下一条消息是ODBC / system / SQL消息，SP代码
不可用且过程失败。连接对象
具有状态2（失败）。命令仍然保留在它b / b
的任何参数中; Recordset永远不会打开。 （跟随例如返回
VERIFY_USER，但对于任何SP都相同）：
[IBM] [CLI驱动程序] SQL0444N例程" ; VERIFY_USER" （具体名称
" SQL071201165900590"）用库或路径中的代码实现
" \VERIFY_USER"，function" VERIFY_USER"无法访问。
原因代码4。 SQLSTATE = 42724
28 ****** @ gmail.com 写道：
[IBM] [CLI driver] SQL0444N Routine" VERIFY_USER" （具体名称
" SQL071201165900590"）用库或路径中的代码实现
" \VERIFY_USER"，function" VERIFY_USER"无法访问。
原因代码4。 SQLSTATE = 42724
这个UDF是由你定义的吗？哪种语言？路径是否会产生任何感觉？ （看起来很可疑）
我想知道这是否与搜索路径有关...
干杯
Serge
-
Serge Rielau
DB2解决方案开发
IBM多伦多实验室
I have a successful app which is used in a variety of client/server
situations. (DB2 8.x.)
I need to update it to have XML capability to interface with several
other external programs. Therefore, I was happy to see that DB2 is
doing what I need with V9.x
I upgraded an experimental server to 9.5 and a client to same. I''m
using UDB for LUW and the server is Windows Server 2003 and the client
is XP. The programing language has been (to date) VisualBasic 6.
Now, suddenly, the Connection object takes about 100x longer to
connect, the Command object takes about 100x longer to collect the
parameters from a stored procedure, and the actual Execution takes
about 100x longer to get a recordset with return of an SQLSTATE to the
Command object!
In addition, there are many unpredictible cases when the application''s
call to a SP cannot find it at all and returns a fatal error!
I have a SINKING FEELING that IBM has mandated more Java -- More slow,
clunky, error-prone Java. Please, someone, tell me that this is not
so.
Or tell me that it IS so, so that I may do what I have to do . . .
28******@gmail.com wrote:I have a SINKING FEELING that IBM has mandated more Java -- More slow,
clunky, error-prone Java. Please, someone, tell me that this is not
so.
Or tell me that it IS so, so that I may do what I have to do . . .There is no Java on the server. So whatever it is it isn''t that.
You symptoms are to generic (more like an aching belly ;-) to give sound
advice. Can you open a PMR?
Alternatively I propose to divide and conquer.
Connect from the CLP. Run some tests.
What happens if the connection is local? Etc, etc...
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
Serge,
I wasn''t thinking of Java on the server, but on the new client. There
seems to be some disk-thrashing during all this (as I said, it takes
much, much longer than before for a connection.
1. Local connection is fine, ie if client and server are on same box,
the Stored Procedure is executed and returns correctly.
2. Remote CLP connections are fine.
3. Direct SQL statements executed from the remote client are fine.
THEN,
4. Calls to stored procedures from the new client (9.5 LUW) to the
new 9.5 server fail. Here''s what happens: (Each of these is a step
in the code on the client:)
a) The client Connection object (via the new ODBC, I think it''s in
MDAC 2.8) makes a very slow connection with the server, with disk
thrashing.
b) Uses Command object to contact the SP and pick up the number and
type of parameters (IN, OUT) via "Prepare Command" in code.
(Obviously can read the SP at this point.)
c) Back at the Client, The Command object is loaded with the values
of the IN Parameters.
d) This returns to the server for the SQL in the SP to run.
e) At this point a "About to Execute (Succes)" Event occurs in the
Connection object which has a Satus of 1 (succes).
Finis. Next message is the ODBC/system/SQL message that the SP code
is unavailable and the procedure has failed. The Connection Object
has Status 2 (fail). The Command remains with whatever parameters it
had; the Recordset is never opened. (Follows an eg of return with
"VERIFY_USER," but same for any SP):
[IBM][CLI driver]SQL0444N Routine "VERIFY_USER" (specific name
"SQL071201165900590") is implemented with code in library or path
"\VERIFY_USER", function "VERIFY_USER" which cannot be accessed.
Reason code "4". SQLSTATE = 42724
28******@gmail.com wrote:[IBM][CLI driver]SQL0444N Routine "VERIFY_USER" (specific name
"SQL071201165900590") is implemented with code in library or path
"\VERIFY_USER", function "VERIFY_USER" which cannot be accessed.
Reason code "4". SQLSTATE = 42724Is this UDF defined by you? Which language? Does the path make any
sense? (It looks dubious)
I''m wondering whether this has something to do with the search path...
Cheers
Serge
--
Serge Rielau
DB2 Solutions Development
IBM Toronto Lab
这篇关于不详的预感的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
