動的なクエリでは、sap hanaプロシージャの変数にcount（*）の値を格納します

Question

私は、カウント（*）の値を変数に格納し、この変数をビジネスロジックに使用する必要があります。働いていない。したがって、プロシージャ内部の動的問合せを使用して、入力パラメータを介してスキーマ名を渡す必要があります。

コード：事前に

Begin 

DECLARE v_count INT DEFAULT 0; 
DECLARE v_Count_Query NVARCHAR(5000); 

CREATE GLOBAL TEMPORARY TABLE RECORD_CNT_TABLE(RECORDS_CNT INTEGER); 

v_Count_Query = 'INSERT INTO RECORD_CNT_TABLE(SELECT COUNT(*) FROM "'||:IP_Schema_Name||'"."TABLE_NAME" where to_dats(to_char("LastRunDay", ''yyyymmdd'')) = '||current_date||';'; 

EXECUTE IMMEDIATE :v_Count_Query; 

EXECUTE IMMEDIATE 'SELECT RECORDS_CNT INTO '||v_count||' FROM RECORD_CNT_TABLE;'; 

IF :v_count >= 1 then 
/**business logic**/ 
ELSE 
/**business logic**/ 
END IF; 

END; 

---

感謝。

Answer 1

以下はHANA2で動作しますが、HANA1では動作しません。

create or replace procedure check_and_do_clients (IN schema_name Nvarchar(256)) 
as 
begin 

DECLARE v_count INT := 0; 

    exec 'select count(*) from "' || :schema_name || '"."APPL_DATA"' 
     ||' where "LastRunDay" = date''01.06.2017'' ' into v_count ; 

    IF :v_count >= 1 then 
       select 'WE HAVE A WINNER!', :v_count as vcnt, :schema_name as schema_name from dummy; 
    ELSE 
      select 'NO LUCK THIS TIME!', :v_count as vcnt, :schema_name as schema_name from dummy; 
    END IF; 

end; 

'WEはWINNERを持っています！' VCNT SCHEMA_NAME
私たちは優勝者です！ 1 CLNT1

ここには一時テーブルは必要ありません。現在のトランザクションの範囲外の値を再利用する予定がある場合でも、グローバルの一時テーブルを作成することは実行時には行われません。 一度作成し、使用する前にTRUNCATE TABLEを使用して空にしてください。データは、セッションがアクティブで、セッションを作成したセッションにしか表示されない限り、生き残ることができます。

これ以上のものは、この手順を書くアプリケーションのより広い設計です。 SQLのスキーマは名前空間であり、SQLが静的に型付けされているので、表"CLNT1"."APPL_DATA"は"CLNT2"."APPL_DATA"とは異なりますが、この設定では動的SQLを使用する理由があります。

多くの場合、私はそのようなデザインに遭遇すると、スキーマの概念が、より具体的には異なるスキームの構造的に同一のコピーを異なる名前空間に持つために使用されます。目標は、異なるデータベースまたはクライアント（旧来のSAPが話している）から同じデータベースにデータを分離することです。

共通の要件は、より高い位置から何かを実行し、そのクライアントスキーマののにあるデータにアクセスすることです。 これはあなたの要件が有効になる場所です。

は、このアプローチの問題がいくつかあります：

• 、動的SQLはSQLインジェクションへの一般的リソースの使用状況に重くなりやすい
• それだ - 書くことはより困難とのみによって確認されます - 見られるように、実行時にデータベースが
• データ・アクセス・パターンは、スキーマに含まれていないコードで直接データアクセスを開くことによって、自己含有クライアント -schemaのモデルを壊し

これに代わるアプローチは、この場合にデザインを逆転させることです。 Xテーブル（各スキーマに1つ）に対して動的なビューを表示する代わりに、スキーマ間で共通のテーブルのスキーマを作成し、代わりに各スキーマにフィルタ付きビューを作成します。

「マスター」スキーマは、「クライアント」スキーマがビューの形で表の「その」バージョンにアクセスできるように、動的SQLを必要とせずに簡単に共有テーブルにアクセスできます。 INSTEAD OFトリガーを使用すると、フィルター条件が適切に追加されるように、INSERT/UPDATEステートメントをビューに対してリダイレクトするのは簡単です。

このアプローチは、動的SQLのアプローチと同様に、SET SCHEMA <schema name>コマンドで関心のあるスキーマに動的に切り替える手順を実行する必要がある実際のクライアントアプリケーションのオプションを除外します。 SET SCHEMAは手続きに役立ちませんが（オブジェクト参照はコンパイル時に静的にチェックされますが、覚えていますか？）、クライアントアプリケーションでコマンドを発行し、SELECT COUNT(*)の結果を後続のビジネスを処理するプロシージャ論理。