183 Views
November 04, 19
スライド概要
Notes/Dominoの@関数を取り上げながら、調べたこと、経験したことを雑談してゆきます。
第16回は引き続き@DbColumと@DbLookupについて。
併せて@IsErrorについて
@ -notes knows community- 2019/10/16 @関数Talk 第16回 公開版 @ ネオアクシス株式会社 阿部覚 (tw:) @abesat
@ 前回に引き続き、 @DbColumn, @DbLookupを お話ししたいと思います まずは前回のおさらい… @ 👉 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さんのページですので、近い将来変わる可能性があります
「エラー」って、具体的にはどういう状態? @ まずは「式が適切な戻り値を返せない状態」と考えましょう たとえば、エラーが発生すると、 式がこんな戻り値になってユーザーさんが困惑します @ 生のエラー戻り値を表示せずに済ませたい場合に 前述の @If(@IsError(~); ~; ~) を使って対策します
@If(@IsError(~); ~; ~) @ “もし、 式がエラーの時には エラーの代わりにこの値を返して エラーがなければ普通の値を返して” @ すなおに適用するとこうなります 一応動作しますが、あまりよくない例です
@If(@IsError(~); ~; ~) @ “もし、 式がエラーの時には エラーの代わりにこの値を返して エラーがなければ普通の値を返して” @ @DbColumnが2回動くムダを防ぎます
@ と、前座的に @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部分について
3種類ほどあるようですが @ ポピュラーなのは[FAILSILENT]です これを使うと @
@ 本来ならエラーになる式に [FAILSILENT]がつくと、エラーは出なくなります @
@ ゆえに「@IsErrorを使った式の代わりになる」と 思っていませんか(私もそう思っていました) 同じ? @
@ しかし、よくよく確認すると、 [FAILSILENT]では、 すべてのエラーが消えるわけではありませんでした ビューが存在しないためにエラー @ DBアプリが存在しないためにエラー
@ エラーが隠れるのは あくまで 探索のキー値が見つからないとき 他のエラーは、状況により、むしろ表示すべきなのかも だって、エラーを隠してしまうということは 前掲のような 「DBが無くなった」「ビューがなくなった」 という障害が発覚しないことを意味しますから @ @IsErrorを使う式(すべてのエラーを帳消し)と、 うまく使い分けていただけたらと思います
@ う と が り あ 聴 ご清 ! た し ま い ざ ご @