1

ここに私のコードのスニペットがあります:

  Set cmd = Server.CreateObject("ADODB.Command")
cmd.ActiveConnection = objCon
       cmd.CommandType = 4
    cmd.CommandText = "SP_USERLOGIN"

       response.Write(p_user_id)
       cmd.Parameters.Append cmd.CreateParameter ("User_locked",adVarChar, adParamInput)
        cmd.parameters(0).value = p_user_id
       cmd.Execute

パラメータを追加しようとすると、次のエラーが発生します。

引数の型が間違っているか、許容範囲外であるか、互いに競合しています。

私のストアドプロシージャは1つのパラメータしか取りません:

create or replace PROCEDURE        SP_USERLOGIN ( User_locked VARCHAR2 ) as
BEGIN
update tusers Set user_account_status='status' where user_id = User_locked;
commit;
END;
4

2 に答える 2

2

adVarCharなどの定数が定義されていないことが問題であることが判明しました。パラメータの長さが定義されていないという 2 番目の問題があった可能性があります (これは 4 番目の引数です)。

これらを定義するファイル名ADOVBS.INCがあり、それが含まれていない場合は、代わりに定数値を使用する必要があります。

これで問題は解決しました...

cmd.Parameters.Append cmd.CreateParameter ("User_locked",adVarChar, adParamInput)

...これに変更されました：

cmd.Parameters.Append cmd.CreateParameter ("User_locked",200, 1, 30)

上記30は の長さの値ですvarchar。

于 2013-06-14T19:51:49.760 に答える
0

不器用な cmd オブジェクトとそのパラメーター処理を置き換えるための小さな (Oracle) 回避策。ストアド プロシージャである PROC1 を実行し、それに 2 つのパラメータを渡すとします。パラメータの型に対応する 2 つのフィールドを持つ DUMMY という名前のダミー テーブルを作成します。どんな値でも1行挿入します。DUMMY に更新前トリガーを作成します。トリガーは、PROC1 とまったく同じことを行う必要があり、そのパラメーターを「更新された」レコード (:new.a、:new.b) のフィールドとして読み取ります。ASP では、「update schema.dummy set a=..., b=...」ステートメントを使用するだけです。短所：非正統的。利点: ASP コードが簡潔になります。簡単なデバッグ。+ ダミー テーブル (ちなみに任意のテーブル) を読み取って、同じ方法で逆方向にパラメーターを返すことができます。

于 2015-02-11T00:24:55.490 に答える