none
VB6 呼叫 Procedure 資料回傳很慢?? RRS feed

  • 問題

  •  

    各位先進好:

    小弟於SQL Server 2005 上寫一Procedure 回傳計算結果。使用SSMS回傳資料不到1秒就可得到結果。

    但使用VB6時,回傳時間變得很久大約要1分多鐘。奇怪的是,呼叫其他Procedure並無此問題,原本以為是寫法的問題,但為什麼用SSMS執行就很快呢? 我的環境是C/S,SSMS裝在Client端,想請問各位先進是否有遇過此類問題呢?小弟該從哪方面著手呢?? 希望先進們能給指點迷津一下~~~

    謝謝感激不盡!!

     

    VB6的呼叫方式:

    Dim rs As New ADODB.Recordset
    rs.CursorLocation = adUseClient

    rs.Open "exec dbo.Usp_RptCasePlanRun1 '" & tmpCenterID & "','" & Trim(Me.txtSubyear.Text) & "'", M_Conn

     

    2009年1月19日 上午 03:30

解答

所有回覆

  • 請使用 Command 來執行 Stored Procedure。

     

    2009年1月19日 上午 04:00
    版主
  •  

    小朱前輩:

    我有使用command來使用procedure,但結果還是一樣ㄟ。

    我的語法如下:

        Dim cmd As New ADODB.Command
        Dim para1 As New ADODB.Parameter
        Dim para2 As New ADODB.Parameter
        
        cmd.CommandType = adCmdStoredProc
        If tselect = 1 Then
            cmd.CommandText = "Usp_RptCasePlanRun1"
        Else
            cmd.CommandText = "Usp_RptCasePlanRun2"
        End If
        cmd.ActiveConnection = M_Conn
        Set para1 = cmd.CreateParameter("CenterID", adVarChar, adParamInput, 3, tmpCenterID)
        cmd.Parameters.Append para1
        Set para2 = cmd.CreateParameter("tsubyear", adVarChar, adParamInput, 3, Trim(Me.txtSubyear.Text))
        cmd.Parameters.Append para2
        Set rs = cmd.Execute
       

    執行的速度還是一樣慢,因而造成逾時的錯誤。再次測試SSMS,執行的速度一秒不到。我有將Procedure改成Function 來執行,還是一樣。但如果使用本機端的SQL Server,速度是正常的。請問我還可以從哪個方面來檢查呢?

     

    2009年1月19日 上午 05:59
  • 跨網路的呼叫,會受到網路頻寬的影響。

    如果網路流量很大的話,會出現 delay 的問題,同時如果抓回來的資料量很大時,也會發生瓶頸的問題。

    2009年1月19日 上午 06:02
    版主
  • 前輩:

    我使用SSMS的用戶端統計資料,得到結果如下

     

    用戶端執行時間                                                                      14:43:06  
    查詢設定檔統計資料   
      INSERT、DELETE 及 UPDATE 陳述式的數目                         84  84.0000
      受到 INSERT、DELETE 或 UPDATE 陳述式影響的資料列        229  229.0000
      SELECT 陳述式的數目                                                         143  143.0000
      SELECT 陳述式傳回的資料列                                               194  194.0000
      交易數目                                                                             84  84.0000
    網路統計資料   
      伺服器往返數目                                                                   1  1.0000
      從用戶端送出的 TDS 封包                                                    1  1.0000
      從伺服器收到的 TDS 封包                                                    3  3.0000
      從用戶端送出的位元組                                                         98  98.0000
      從伺服器收到的位元組                                                         10968  10968.0000
    時間統計資料   
      用戶端處理時間                                                                   47  47.0000
      總執行時間                                                                         375  375.0000
      伺服器回應的等候時間                                                         328  328.0000

     

    資料量不是很大,網路壅塞的話應該不會。因為都是同一區網也同一機器。使用程式和SSMS速度差別就是不一樣。

    這問題真的很怪~~~~ = = a

    2009年1月19日 上午 06:53
  • 你可以先看看:

    http://msdn.microsoft.com/en-us/library/aa175762(SQL.80).aspx

     

    另外,你要把用戶端起始時間,和真正伺服器在執行的起始時間,結束時間,以及用戶端完成指令的時間記下,才能比對出到底是哪個地方出現 delay,光這樣看根本看不出來 ...

     

    2009年1月19日 上午 07:15
    版主
  • 多謝前輩的指點,我會好好研究一下,再來報告。^^

    2009年1月19日 上午 08:46
  • 問題解決了,很奇怪的問題。我把Store Procedure 重新 create 一次就正常了。

    一樣的程式碼,真是怪了。不過多謝小朱前輩的幫忙~~~ thanks

    2009年1月22日 上午 08:04
  • 真的太太太感激你了!!~~~

    我遇到一模一樣的問題, 卡了我2個禮拜, 沒想到按照你的方式把 Store Procedure 重新建立一次就超快了!!!

    感激不盡!!~
    2009年4月6日 上午 10:27
  • 這表示 stored procedure 需要做 RECOMPILE 以重建執行計畫。
    如果那支程序經常需要 RECOMPILE 的話,可以設定它每次執行時都做 RECOMPILE。
    小人物一枚。
    2009年4月6日 上午 10:35
    版主