201910 のの会@関数Talk 16th | Talks around @Functions in Notes and Domino

@ -notes knows community- 2019/10/16 @関数Talk 第16回 公開版 @ ネオアクシス株式会社 阿部覚 (tw:) @abesat

@ 前回に引き続き、 @DbColumn, @DbLookupを お話ししたいと思います まずは前回のおさらい… @ 👉 https://www.slideshare.net/abesat/201908-talk-15th

• https://www.slideshare.net/abesat/201908-talk-15th

@ 前回に引き続き、 @DbColumn, @DbLookupを お話ししたいと思います 前回、使用したサンプルフォームを 引き続き説明に用います @ ＠DbColumnや@DbLookupを使った式 式の結果を表示する 表示用の計算結果フィールド

@ @DbColumn, @DbLookupの 引数について駆け足で触れましたが @DbColumn ( class : cache ; server : database ; view ; columnNumber ) @DbLookup ( class : cache ; server : database ; view ; key ; columnNumber または fieldName ; keywords ) @ 前回残していた＠DbLookupの keywords部分について軽く確認 でも、その前に予備知識として…

@ @IsError の雑談 @

@ そのまま「エラーだよ」関数と 覚えていただければよいのではないか @If(@IsError(～); ～; ～) @IsErrorに限らず、「@Is～」形式の@関数は、 ● ● @ 戻り値は1か0。TrueかFalse、ないしはYesかNo @Ifとセットで使用することが多いと思います @If(@Is～(～); ～; ～)

「エラー」って、具体的にはどういう状態? @ @DBColumn、@DbLookupでも、 呼び方によっては「エラー」を返します ここではあまり深く立ち入らないようにしますが 興味のある方はこちらをご参照 「（参考）@DBLookup および @DBColumn で出力される エラーのリスト」 @ https://www.ibm.com/support/pages/（参考）dblookup-およびdbcolumn-で出力されるエラーのリスト ※現時点でまだIBMさんのページですので、近い将来変わる可能性があります

• https://www.ibm.com/support/pages/

「エラー」って、具体的にはどういう状態? @ まずは「式が適切な戻り値を返せない状態」と考えましょう たとえば、エラーが発生すると、 式がこんな戻り値になってユーザーさんが困惑します @ 生のエラー戻り値を表示せずに済ませたい場合に 前述の @If(@IsError(～); ～; ～) を使って対策します

@If(@IsError(～); ～; ～) @ “もし、 式がエラーの時には エラーの代わりにこの値を返して エラーがなければ普通の値を返して” @ すなおに適用するとこうなります 一応動作しますが、あまりよくない例です

@If(@IsError(～); ～; ～) @ “もし、 式がエラーの時には エラーの代わりにこの値を返して エラーがなければ普通の値を返して” @ @DbColumnが２回動くムダを防ぎます

@ と、前座的に @IsErrorに触れたところで 少し趣向の違うことを お話ししたいと思います @

@ @DbColumn @DbLookUp で、私が引っかかってることを とりあえず話してみる篇 @

@ ここで、私にとってのキーワードは 楔 @ 柵 くさび ないしは しがらみ です

@DBColumn,@DbLookupについて @ 私が一番気にしていること A @DbLookup(“”; B ... B @ とくにDBアプリ間で使用することで 「くさびを打ってしまう」こと 「しがらみを作ってしまう」と言い換えてもよい

@ ひとたび他所のDBアプリから@DBColumnされると ビューの列順などをうっかりいじれなくなる ひとたび他所のDBアプリから@DBLookupされると ビューのソート順、列順などをうっかりいじれなくなる あるいは、要らなくなったからといって うっかりビューを消せなくなる @ あるいは、要らなくなったからといって うっかりアプリを消せなくなる

@ もしいじったり、消してしまうと… ちわーっす @DbLookupしたいんすけど XXビューさん いらっしゃいますかね？ こちらの DBアプリ え？、XXは もう、居りませんけど ええーっつ！ （泣） ERROR 他所の DBアプリ @

一番「他所のDBアプリから参照されそうな」存在 @ ドミノディレクトリには大量のビューがあります @

一番「他所のDBアプリから参照されそうな」存在 @ ドミノディレクトリには大量のビューがあります バージョンを重ねるうちに追加されてきた これらのビューで将来、列が変動したり、 ビューが削除されることは、ほとんどないのでは どのユーザーがどんなアプリから 参照しているか、わからないから @ しかし、マスターである（参照されることが使命である） アプリであれば、それでも良いのかも

@ @DbColumn, @DbLookup で 既存のビューを参照するときには 相手先のビューのことも考えて 設定してあげることが必要と思います （特に、他DBアプリに対して行うとき） 逆に言うと、マスター側のDBアプリでは あらかじめ計画し、汎用的に使える適切なビューを 用意しておけばよいと思います @

こうした、 @ 「しがらみをつくる」 「くさびをうつ」 性格を持つ関数 簡易言語である式言語では @DbColumn, @DbLookup が唯一に近い 代表格かと思います （スクリプト系には他にもありますが…） 使い込まれたNotes/Dominoが敬遠される けっこう大きな要因の一つではないかと この2つの関数や、 参照先のビューの設計・利用には ある程度のプランが要るなと 感じる次第です @ ご利用は計画的に♥ ご利用は計画的に ご利用は計画的に♥ ご利用は計画的に

@ さて、当初のお話に戻ります @DbColumn ( class : cache ; server : database ; view ; columnNumber ) @DbLookup ( class : cache ; server : database ; view ; key ; columnNumber または fieldName ; keywords ) @ 前回残していた＠DbLookupの keywords部分について

３種類ほどあるようですが @ ポピュラーなのは[FAILSILENT]です これを使うと @

@ 本来ならエラーになる式に [FAILSILENT]がつくと、エラーは出なくなります @

@ ゆえに「@IsErrorを使った式の代わりになる」と 思っていませんか（私もそう思っていました） 同じ？ @

@ しかし、よくよく確認すると、 [FAILSILENT]では、 すべてのエラーが消えるわけではありませんでした ビューが存在しないためにエラー @ DBアプリが存在しないためにエラー

@ エラーが隠れるのは あくまで 探索のキー値が見つからないとき 他のエラーは、状況により、むしろ表示すべきなのかも だって、エラーを隠してしまうということは 前掲のような 「DBが無くなった」「ビューがなくなった」 という障害が発覚しないことを意味しますから @ @IsErrorを使う式（すべてのエラーを帳消し）と、 うまく使い分けていただけたらと思います

@ う と が り あ 聴 ご清 ！ た し ま い ざ ご @