テーブルから全ての計算式をはずすとどうなるのでしょう？

過去の桐井戸端ＢＢＳ　（桐ver.９）

19855	テーブルから全ての計算式をはずすとどうなるのでしょう？	しぼうかん	2003/04/12-00:44
また変な質問をさせて頂きます。少しばかり知識が増えて、いままで表に計算式を書いてやっていた方法をイベントで出来る様になって来ました。そこで、並べ替え条件を除く全ての計算式をテーブルからはずして、イベントファイルのコマンドで実行したり、フォームに書いた設定で実行した方がいいんじゃないか？と思うようになってきました。理由として３つ思いつきました。１.テーブルに書いた計算式とフォームやイベントファイルに書いた計算式の関係を考えなくていいし、計算式のチェックもテーブルに関してはしなくてもよくなるので計算式の追加や、修正や、ミスの発見がしやすい。実際イベントに記述した内容通りにうまくいかないので調べてみたら、編集初期値式に設定してあった計算式が原因だったという事もありました。２.ＥＸＣＥＬなどとのデータの受け渡しの時にテーブルには計算式がないほうが、やりやすかったり、ミスが起きにくい様な気がする。３.ファイルのデータ処理が早くなる様な気がします。ファイルの共有をする場合はなおさらテーブルのファイルサイズを小さくしておいた方が処理が早くなるような気がします。（ファイルの共有はした事は無いのですが。）１.～３.共に根拠のない想像なのですが、テーブルから全ての計算式をはずす事で何かの機能が実行出来なくなったり、問題が起きることはありますか？
19859	Re:テーブルから全ての計算式をはずすとどうなるのでしょう？	悲しげ	2003/04/12-11:02
記事番号19855へのコメント組み方によって千差万別ですので、結論としては、自分で組んだデータを使って自分で実験するしかないでしょう。その試行錯誤の結果、ここは抜いた方がいいとか、ここは残しておいた方がいいとか決まると思います。※ ※かと云って、しぼうかんさんの個々の事例の詳細を、この場で延々と挙げられるのは、別に止めはしませんけど・・・・・(^^;) この辺りを一般論として云いきることは絶対的に困難かと想像します。強いて云えば「各人の好み」程度かもしれません。ちなみに私は、その辺りは、よく云えば「適材適所」、そのココロは「行き当たりバッタリ」のような気がします。 ps.実験に当たってはくれぐれも（他フォルダ等への）バックアップをお忘れなく。
19862	Re:テーブルから全ての計算式をはずすとどうなるのでしょう？	うにん	2003/04/12-11:54
記事番号19859へのコメント >この辺りを一般論として云いきることは絶対的に困難かと想像します。 >強いて云えば「各人の好み」程度かもしれません。ちなみに私は、その辺 >りは、よく云えば「適材適所」、そのココロは「行き当たりバッタリ」の >ような気がします。そうですよね～。表自体は軽くなるでしょうけど、うっかり表を直接開いてしまったら無意味な値に変えられてしまう可能性があるし。
19868	具体例を一つ教えてもらいたいのですが？	しぼうかん	2003/04/12-17:56
記事番号19859へのコメント悲しげさん、いつもお返事ありがとうございます。今回はなるべく錯綜しないように努力したいと思っています。＞テーブルから全ての計算式をはずす事で何かの機能が実行出来なくなった＞り、問題が起きることはありますか？という質問について悲しげさんがいままで作ったシステムのなかで「適材適所」だとテーブルに計算式を書いた方がいいと判断された場合はどのような場合なのでしょうか？各論というより、具体例が知りたいのですが、例えば、例１)テーブルの"表引き条件"に書いた計算式と同等のことはイベントでは出来ない。 ※例１は実際は出来るのですが最近までその方法を知らないでテーブルに計算式を書かないとダメだと思っていました。というようなイベントやフォームの設定では出来ない機能についての実例があれば「適材適所」の意味がわかりやすいのですが、出来ればよくある様な具体例を一つ紹介して頂けませんでしょうか？
19869	この解釈はハズしていますか？	しぼうかん	2003/04/12-18:07
記事番号19862へのコメントうにんさん少しお世話にならせて下さい。＞うっかり表を直接開いてしまったら無意味な値に変えられてしまう可能性が＞あるし。これは「うっかり表を直接開いて編集してしまったら・・・という風に読み替えていいですか？たぶんテーブルから計算式をハズしていまえばテーブルを開いただけでは値が変わる事は無いと思うので。そうだとすると、フォームからの入力を原則としているシステムでテーブルからの編集をする事によって問題が生じるとすれば、それはテーブルに計算式を設定しているかどうかにかかわらず、同様に「無意味な値に変えられてしまう可能性があるし」という事があるような気がします。そこでこの場合は、テーブルから計算式をハズした場合の問題点とは言えないように思うのですが、この解釈はハズしていますか？
19871	Re:「テーブルの計算式」	悲しげ	2003/04/12-19:09
記事番号19868へのコメント「テーブルの計算式」と云うと普通は「項目計算式」を指すと思います。ところが、書かれたことをよく見ると #19855では >編集初期値式に設定してあった計算式 #19868では >テーブルの"表引き条件"に書いた計算式とありまして、どうやら「項目計算式」ではないのでしょうか？とりわけ、「表引き条件」には「計算式」は無かったと思います。「項目属性」の設定で「計算式」が出てくるのは、挿入・編集の初期値式、項目制約式、行制約式の筈です。しぼうかんさんの云う「テーブルの計算式」とは何なのでしょう？
19872	「テーブルの計算式」の解釈ふたつ	悲しげ	2003/04/12-19:44
記事番号19871へのコメント「テーブルの計算式」を、字義どおり項目計算式と解釈した場合、そのまま使う方が便利だから、そのように設定してあるのだと思います。云い換えれば、cmdなりkevなりでシコシコ記述して取得するよりも楽だし、何よりインタプリタ（であるcmdなりkevなり）を介さない分、高速だと思います。ひとつの例として「#表引き」関数などがあると思います。あえてこれらを使わないで、cmdやkev経由にするのは、例えば入力値を手動で書き換えたい場合とかが思いつきます。そうではなくて、つまり「テーブルの計算式」と云ったのは用語的間違いで、実は表定義の「項目属性」の各種設定のことを指すのだとしたら、それこそお好みだと思います。項目属性の設定を生かしたままに処理をさせるか（その方が簡単でしょうしね）、あるいはより細かく制御させたいがためにそれらの設定を抜いて、もっばらcmdやkevの記述からやるようにするか、ですね。ひとつ云えることは、項目属性の設定とkevの処理の両方を使わない方がいいと云うことでしょう。どちらか片方にすべきです（どちらが良いとは云えません、それは好みですから）。両方設定していた場合は、互いに矛盾している場合は勿論のこと、同じ場合であってもしばしばバッティングしてエラーっぽくなった経験があります。例としては、[月]項目について、項目制約式で１～12と設定してあって、なお且つkevでもそのことをチェックさせているとか。これは、特にkevの場合に多かったような印象がありますが、でも、 cmdで試す経験がこのところ乏しいだけなのかも？
19873	Re:「テーブルの計算式」の解釈ふたつ（補足）	悲しげ	2003/04/12-19:57
記事番号19872へのコメント >さない分、高速だと思います。ひとつの例として「#表引き」関数 >などがあると思います。あえてこれらを使わないで、cmdやkev経由「#表引き」関数は、項目属性の初期値式で使う場合と混乱するかもしれないので、例を　　#直前値([某項目],0)+1 に変えておきます。(^^;) これなんかcmd・kevで繰り返しループを使ってやると結構遅いです。
19874	ありゃ、また説明ミスでした。	しぼうかん	2003/04/12-19:57
記事番号19871へのコメントあっちゃー、やっぱり説明ミスがありました。(^_^; １）私が使った言葉"テーブルの計算式"とは挿入・編集の初期値式、項目制約式、行制約式、更新、自動複写、値集合条件、表引き条件、ガイド・エラーメッセージ、重複値、未定義値、入力モード、編集モードに設定された事全ての事を言うつもりでした。２）に続く ※これを書いていて気が付いたのですが"被ふりがな項目名"への設定をイベントでやる方法はわからないので、これは"並べ替え条件"と同じくイベントやフォームじゃなくてテーブルに設定しなければならない事の内の一つかもしれません。２）例えばＣＳＶファイルに書き出した場合無効になる設定は全て"テーブルに設定された計算式"という風に解釈してもらえれば・・・これで意味は伝わったでしょうか？
19875	Re:テーブルから全ての計算式をはずすとどうなるのでしょう？	悲しげ	2003/04/12-20:12
記事番号19855へのコメントしぼうかんさんはどうも「一般論」を求める質問が目立ちますね。「一般論」は一般的には応え難い設問だと思いますよ。と云う訳で、できるだけ個別的・具体的に質問される（ように自らを訓練する）ことを、お勧めしておきます。 ps: できれば、この投稿にはコメントを付けないで下さい。(^^;)
19876	Re:ありゃ、また説明ミスでした。	悲しげ	2003/04/12-20:25
記事番号19874へのコメント１）は要するに、正しくは「計算式」ではなくて「項目属性」の設定のことであったと云うことですね？とすれば、#19873の後段でコメントしたとおりです。「どちらも」ではなく「どちらか」であって、そのどちらを使うかは好みの問題に過ぎません。２）については文意を読み取ることができませんでした。このことが、なぜ「１）から続く」のかも不明です。う～ん、もしかすると１）も読解できていないかもしれません。
19878	Re:ありゃ、また説明ミスでした。	うにん	2003/04/12-20:35
記事番号19874へのコメント >１）私が使った言葉"テーブルの計算式"とは挿入・編集の初期値式、項目制 >約式、行制約式、更新、自動複写、値集合条件、表引き条件、ガイド・エラ >ーメッセージ、重複値、未定義値、入力モード、編集モードに設定された事 >全ての事を言うつもりでした。２）に続く >２）例えばＣＳＶファイルに書き出した場合無効になる設定は全て"テーブル >に設定された計算式"という風に解釈してもらえれば・・・私は「計算式」と聞いて項目計算式のことだと思っていましたが、この（２）だと、それも含まれますよね。「書きかえられてしまう」とは、例えば税率5%で計算する消費税の項目に計算式を設定していないと、任意の値が入力できてしまうという意味です。（１）の中で、制約式と、「その他」を禁止した値集合は、表の条件ですから設定をはずすと何かの拍子に矛盾したデータを持ってしまう可能性があります。他は全部、入力や表示の便宜のために設定するものですから、しぼうかんさんの思ったように、 kevが発達した今となっては必ずしも表に設定する必要はないと思います。全部wfmで作りこむシステムなら、いいんじゃないですか？（でも、処理は早くならないと思う…）
19879	一般論としての計算式の設定	佐田　守弘	2003/04/12-21:00
記事番号19855へのコメントしぼうかんさん御質問は、一般論として表から全ての計算式をはずすとどうなるか、なので一般論としてコメントします。各論としてはこれと異なる部分がある事はご承知置き下さい。その前に確認します。 >１私が使った言葉"テーブルの計算式"とは挿入・編集の初期値式、項目制 >約式、行制約式、更新、自動複写、値集合条件、表引き条件、ガイド・エラ >ーメッセージ、重複値、未定義値、入力モード、編集モードに設定された事 >全ての事を言うつもりでした。との事ですが、最も大切な「項目計算式」を忘れてますね。表で最も大切な式は、この項目計算式なのですが。それとも項目計算式は除外ですか？ ●桐の表での計算式や条件の設定機能はデータベースをデータの容れ物と考えれば、元来は計算式や条件の機能 (以下計算式等と略記)は、一切不用です。これらはその都度、プログラムで値を決めて書き込めばよいのですから。では桐の計算式等の機能は何のためにあるのかですが、これは入力を便利にするための機能です。 Excelなどでの入力と比べて、桐はデータの入力をやりやすいのは、ひとえにこの計算式等の機能によります。いうなれば、桐の計算式等の機能は、桐の最も美味しい部分です。 ●既存の表から計算式等を外すと値は変更前の値が保持されますから、値が変わったりはしません。その代わり、各種の自動入力が無効になりますから、それ以降の入力操作がとても煩わしくなります。感触で言えば、「桐は大変入力しやすい」から「とても使いにくい」に変わる事を請け合います。 ●フォームとイベントでその機能が代替えできるのか主要な部分の機能は、イベント等を使って、実現できます。ただし、ふり仮名入力はできません。またかな漢字変換の設定もちょっとむりでしょうか。これらの機能によって、フォーム上ではほぼ同等の機能を実現できます。またイベントだけでなく、フォーム上の設定で入力モードを設定するなど表と同じ内容の設定をフォームで行う事もできます。しかし、表編集を行う時には、これらの機能が使えませんから、入力がはなはだ不便になります。 ●一般論としての結論桐を使う場合には、可能な限り、表の上で各種の設定を行って下さい。これが原則であり、桐の賢い使い方です。そして表の上での設定ではできない部分のみ、イベントを使って補助します。各論としては一部変わる時もあるかと思いますが、総論として言うならば、「可能な限り表に設定する計算式等を活用するのが、本来の正しい使い方」が結論です。佐田守弘(KS-00119) ●補足：敢て行う「賢くない使い方」時には敢て、上記と反した設定を行う事も考えうる話です。例えば、販売するシステムを販売先にコピーして利用されないようにと、各種設定を表の定義やフォームの定義、イベントなどに分散して設定し、直そうと思っても直す事を困難にする方法はあり得る事です。一箇所直しても直らないので、手直しや改造を断念させるには、有効な方法です。もちろん、作った本人でも後日直そうとすると苦労する事になります。
19881	なんとか考えの整理が出来ました。	しぼうかん	2003/04/12-21:14
記事番号19878へのコメントうにんさん、お返事ありがとうございます。説明よくわかりました。＞「書きかえられてしまう」とは、例えば税率5%で計算する消費税の項目に＞計算式を設定していないと、任意の値が入力できてしまうという意味です。＞（１）の中で、制約式と、「その他」を禁止した値集合は、表の条件ですから＞設定をはずすと何かの拍子に矛盾したデータを持ってしまう可能性があります。入力後イベントの"入力継続"などを使えば表にある"行制約"や"項目制約"などは代用出来ると思っていましたが、なにかの拍子に表から入力する可能性は確かにあります。そしてその場合"項目計算式"で設定して置けば表からの入力は不可能なのでその点でシステムとして安全性が高いということになりますね。処理スピードに関しても私が勘違いしていたようで、悲しげさんもおっしゃる様に表に計算式を書いた方が早い場合も多々あるみたいなので、表の計算式を全てハズすのは諦めて併用する事にしました。
19882	おかげさまで結論にたどりつきました。	しぼうかん	2003/04/12-21:32
記事番号19879へのコメント佐田先生、いつもながら私の頭でも非常にわかりやすい解説ありがとうございます。＞との事ですが、最も大切な「項目計算式」を忘れてますね。表で最も大切な＞式は、この項目計算式なのですが。それとも項目計算式は除外ですか？もちろん「項目計算式」も入っています。書き漏れでした。すいません。＞●フォームとイベントでその機能が代替えできるのかこの部分は処理スピードに関する事と同様にもっとも知りたい所でした。＞●一般論としての結論＞桐を使う場合には、可能な限り、表の上で各種の設定を行って下さい。＞これが原則であり、桐の賢い使い方です。＞そして表の上での設定ではできない部分のみ、イベントを使って補助します。＞各論としては一部変わる時もあるかと思いますが、総論として言うならば、＞「可能な限り表に設定する計算式等を活用するのが、本来の正しい使い方」＞が結論です。自信の無い人間はこういう風に強い言葉を頂けると安心できます。表への設定を主にしてイベントは補助的に使う事に決めました。ありがとうございました。 ※しかしかなりの部分をイベントに書き換えてしまったのでまた表への書き戻しは大変です。(_)
19883	なんとか結論が出ました。	しぼうかん	2003/04/12-21:43
記事番号19876へのコメント悲しげさんのコメントに追いつけずに、なんかゴチャゴチャしてしまいすいません。 NO19876 ＞１）は要するに、正しくは「計算式」ではなくて「項目属性」の設定＞のことであったと云うことですね？はい、間違いなく１００％そうです。＞）については文意を読み取ることができませんでした。このことが、＞なぜ「１）から続く」のかも不明です。う～ん、もしかすると１）も＞読解できていないかもしれません。 ※の注釈をいれてしまったので文章がとんで読みにくいかと思い"２）に続く"と書いたのですが逆に混乱させてしまったようです。２）に関しては１）をわかりやすく説明しようとしたのですが逆噴射でした。 NO19872 ＞ひとつ云えることは、項目属性の設定とkevの処理の両方を使わない＞方がいいと云うことでしょう。どちらか片方にすべきですはい、今はこれはしてません。苦いバッティングはすでに経験してしまったので。(^^;) NO19872とNO19873の２つのお返事には処理スピードについて書かれていましたが、やりたい内容によりテーブルに設定した方が早くなる場合が多々あるということですね。どうも自信が無いので失敗を恐れて「一般論」という安全で広い道を進みたいと思い、自分では桐でのシステム作りに関する具体的な質問のつもりでしたが、他の方からみると抽象的な質問になっていたのかもしれません。まず実際の処理スピードを試しながら、スピードに大きな差がある物や、うにんさんが言われている"何かの拍子に矛盾したデータを持ってしまう可能性"を防ぐ為にテーブルの計算式を併用する方向でいこうと思います。沢山のお返事ありがとうございました。
19892	私も全く同じ事をしました。	桐香	2003/04/13-19:30
記事番号19882へのコメントしぼうかんさんはじめましてもう結論が出ているので余計な事で申し訳ないのですが、私も全く同じ考えで同じ事をしました。これから表に書き換えるご苦労を考えますと昨年の私を思い出しご同情申し上げます。私は時間貸し駐車場の経営をしていますが、２年前駐車場専用レジ(アマノ２００万)のリース切れをきっかけに桐でつくろうと一年勃起、桐のイベントにも恵まれてそれらしいものが完成して現在稼動中です。自分で言うのもなんですがアマノのレジより比べようもなく高機能です。私のイベント処理は第三者が触ることを前提にしています。そしてそのイベントを見直すときにしぼうかんさんと同じ発想で表の項目計算式を全てはずしてイベントに書き込んだのです。これで昔使っていたＤＢⅣシニア風になったと自己満足していました。第三者に入力させやすいようにするのがイベントの最大の目的でしたから、メンテナンスは自分で手動でやればよかったのです。ところが表に計算式がないと簡単なメンテナンスもイベントをとうして、つまり新たにイベントを書かなければならないことに気が付いたのです。もちろん全てをイベントで書けばいいことですけど。例えば一件お客さんのデータを入力モレになっていた...こういう場合は表を開いて挿入してやれば簡単な事ですが計算式がないため、入力モレのイベントを作らなければなりません。この部分も第三者にさせるのなら必要ですが。長々と書きましたが悲しげ先生、佐田先生のおっしゃられるようにケースバイケースではないでしょうか。 (両先生に教えていただいた「編集文字列の全選択」は活躍しています..Ｖ９では簡単にてきるのでしょうが) それにしても桐のイベント処理はすばらしいですね。そのすばらしさがつい全部イベントでやろうという気にさせるのです。イベントが旦那で表が奥さん(その逆もあるかな？)。旦那が万能でも奥さんも頼りにしないと家庭不和の元。同じ考えで実行してしまったしぼうかんさんに親近感をおぼえつつ失礼致します。
19893	貴重な経験談ありがとうございます。	しぼうかん	2003/04/13-21:37
記事番号19892へのコメント桐香さん、こんばんは。私と同じ経験をなさった方からのご意見はなんかうれしいですね。システムも業務に合わせてケースバイケースというのはわかっていたのですが、選択肢が複数あってどちらでも良い場合はやっぱり"みんなで渡れば怖くない"じゃないですがなるべく沢山の方と同じ道をすすんで行きたいと思いました。この様な質問はユーザーサポートでは答えをもらえないので、親切に答えて頂ける方々がおられるこの様な掲示板は本当に助かります。
19909	Re:テーブルから全ての計算式をはずすとどうなるのでしょう？	悲しげ	2003/04/14-15:07
記事番号19855へのコメント似て非なることかもしれませんが、類似と思われるようなことを私も考えたことがない訳ではありません。ただし、動機は少し違っていて、こう云うことでした。ある値を取得するのに、ある場合は表の項目計算式の#表引き、あるものはcmdで、あるものは表の項目属性の表引き、あるものは表の項目属性の値集合、あるものはフォームの入力支援ボタンのリストボックス、そしてあるものはkevから（例えば「（仮称）拡張表引き」・・・、のように実に色々なパターンがありまして、これらを混在させて作っていたとします（それは自分の「成長の軌跡」でもあったりする訳ですが）。となると、作成後かなり経ってからだと、どこをどのようにしてこの値を取得していたのかが、自分自身でワケワカメになってくること必定です。だから、特に桐Ｖ５のころに、全てcmdで管理させた方が、後日のメンテが楽なのかもしれないなどと思ったものです。が、皆さんも挙げていただいたように、やはり「適材適所」の問題がありましたし、何より「行き当たりバッタリ」を根本から作り変えるエネルギーのこともありまして、それも無理です。となると、主要な問題は「ワケワカメ対策」となります。私は、なるべくこの辺りをメモっておくようにしようと思っています。表定義やフォーム・結合表の定義等には殆ど記述できませんから、結局はkev（あるいはcmd）の中に注釈行として、これらを細々とメモしておこうと云う訳です。ただし、そのことを忘れる方が多かったりしますが。(^^;) 以上、参考にはならんかもしれませんが。
19935	どんな事でも参考になります。	しぼうかん	2003/04/15-00:20
記事番号19909へのコメントこの質問をする前に一応過去ログを調べてみたのですが、それらしい質問が無かったのですが、他の人はたぶん苦労して桐を使い込む内に自然に理解していったんですね。私はちょっと楽をさせてもらいました。ｋｅｖにメモする方法は、まだ未完成でしょっちゅう訂正しているので、完成した後に意味を忘れてしまいそうなあぶない所にはこの方法を採らせて頂きます。

戻る