@Shuichi Igusa さん

こんにちは。
全てではないですが、下記にある程度まとまっていそうです。

https://docs.intersystems.com/iris20221/csp/docbookj/DocBook.UI.Page.cls...

あとは個人的に開発をするときには、クラスリファレンスとか見ながら、
こんなアダプタとかあったのか!みたいな調べ方をしていました。(EnsLibパッケージの中です。)

Hashimotoさん

コメントいただきありがとうございます!
私の方ではSourceControlをコンパイル時の静的解析のような役割で使っておりまして、
それはVSCodeからsave->import->compileの時でも動作することを確認済みです。

> IRISへの接続中のアカウントを取得したいという事でしょうか?
VsCodeのsettings.jsonで設定したアカウントが、Save等によりIRISにImportを行ったときのユーザー情報になります。
..Usernameは接続が確立したタイミングには入っているものと思ったのですが、
今取得すると空になっています。

開催のご連絡ありがとうございます!

早速一つ投稿しようと思ったのですが、グループに「IRIS contest」が無いように思われます。

一度ご確認いただいてもよろしいでしょうか。

Minamoto さん

ご回答いただきありがとうございます!
記載の動作はパラメータの指示によるものだったのですね、、、存じ上げませんでした。

回避しようとすると、EXACTやTRUNCATEを使うのがよさそうですね。
デフォルト値を変えるのが少し怖いですが…。

こちらでも試してみるようにします!

確かにこれであれば、プログラム管理上に.MACが現れることもないので、
.CLSに絞った状態で管理できそうですね!

参考にさせていただきます。
ありがとうございます!

Minamoto さん

ご回答いただきありがとうございます!
やはりイベントを直接拾うことは難しそうですね。

定時頂いた案も利用できるとは思うのですが、
%ZMIRRORの代替えとはいかなさそうなので、方針含め考え直してみます。

ありがとうございました!

Minamoto さん

あけましておめでとうございます!
今年もよろしくお願いいたします。

ご回答いただきありがとうございます。

記載いただいた内容はネームスペースの起動を監視できるという所で、
私の要望していた通りのものかと思いますので、一度実験してみようと思います。

また参考までにお伺いしたいのですが、この監視機能の中で、
%ZMIRRORの代替えとして利用できるものはありそうでしょうか…?

%ZMIRROR…プライマリとしての起動時のみ呼ばれる。セカンダリがプライマリに切り替わったタイミングでも呼ばれる。

こんにちは。

私はCSPの変更の経験がないので同様の現象になったことが無いのですが、
症状から見るに、Cache'というよりかはVScodeの設定の話かなと思いました。

VScodeにはExcludeという設定があり、指定したパターンに該当する項目を
非表示にする仕組みがあります。こちらに該当していたりしないでしょうか?

https://dlrecord.hatenablog.com/entry/2020/11/22/144540

Minamotoさん

ご回答ありがとうございます。
なるほど、IRISとしては特に問わないという事ですね。
わかりました!

環境変数等の情報もありがとうございます。
躓きそうなポイントですね。注意して進めるようにします。

すいません。
②について動作差異の原因がわかりました。

対象のカラムはNOT NULL制約をかけているのですが、
INSERT時にはパフォーマンス優先して%NOCHECKのオプションを付けていました。

NOT NULLのカラムにNULLが入っている時に記載したような振る舞いとなるようです。

こちらについては、私のプログラム側の問題と思いますので、対応するようにいたします。

Toshihiko Minamoto さん

ご確認いただきありがとうございます!
こちらでも、今問題となってるテーブルから問題のカラムを抽出して
新たなテーブルを作成し、そこに対してIS NULLで検索をかけますとヒットすることが確認できました。



テーブルのデータ件数なのか、Insertのやり方なのか、何か条件がありそうですので、
もう少し絞り込めましたら、改めてサポートに問い合わせてみようと思います。

Mihoko Iijima さん

ご確認いただきありがとうございます!
そういう事だったんですね。
インジェクション対策として、パラメータを分けることを基本方針にしていたのですが、
設計を見直す必要がありそうですね・・・。

Hashimotoさん

ありがとうございます!
カラム名を渡されたらそちらの%Metadata.columnsから番号を取得して、
%GetRow()で引っ掛けてみる、という事ですね。

一度試してみようと思います。

Minamotoさん

ご回答いただきありがとうございます。
そちらの方法も検討したのですが、SELECTで*を使って取得した場合や、
複数のテーブルを結合してアクセスした際に、番号を把握しにくいというのと、
SQLのメンテナンスによって列番号が変わった際の保守性が低いという所より、見送りました。

やはりパフォーマンス劣化は避けられなさそうでしょうか…。

DynamicObjectに対して、「.name」でアクセスするのと、「%Get()」で動的にアクセスするのでは、
実質動作に差異がないと思っていたのですが、SQLからの取得結果へのアクセスとなると、
内部でカラム番号の変換処理が必要になってる、という事なんですね。。。
(であれば、何故直接「.name」でアクセスするのが早いのかは気になりますが…。)