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

25075	項目計算式にカウンタ型の項目は使えないのでしょうか	マリリン	2004/02/25-07:59
はじめてです。 表の中で[コード]の項目にカウンター型を使用しています。 そしてこの[お客様コード]をつくり 項目計算式に#文字列([コード],5)としましたところ 「カウンター型は変換できません」とでます どうすればいいのでしょうか？
25077	Re:カウンター型	宮城	2004/02/25-09:18
記事番号25075へのコメント マリリンさん、こんにちは。 カウンタ型は項目計算式ソースに使えないようなので、項目初期値式に #直前値( [] ,0)+1 とされてはいかがですか。 厳密に連番は保証されませんが、お手軽なのでよく使ってます。 あえて欠番発生させたいとき便利ですよ。
25078	Re:カウンター型	hidetake	2004/02/25-09:55
記事番号25077へのコメント >カウンタ型は項目計算式ソースに使えない どうして，桐は「カウンタ型」項目を項目計算式に使えないのでしょう？ で，[項目] の形式では無く，#項目属性(1,0) と言うように「#項目属性」関数を使えば， データそのものは取れる事は取れるのですが，少し面倒な動きをします。 例えば，１番目の項目をカウンタ型の項目とし，この値を利用したい項目に項目計算式として， #項目属性(1,0) や #str(#項目属性(1,0),4)　と言った計算式を設定しておきます。 こう言った表でデータを入力していくと，カウンタ型の項目にデータを入力せずに未記入のままで， 次のレコードに移ると，移動した途端にカウンタ型の項目にはデータが入るわけですが， この値を参照する「#項目属性」関数を使った項目では，その値は 0 になります。 この状態で「#項目属性」関数を使った項目に正しい値を反映させるには 再度，行訂正を行い再計算が発生させられるような状況を作ってやるか？ 置換等で再計算を行う必要があります。 カウンタ型の入力の場面で，未記入で無く，手入力で入力した状態で 次の行にいくと，「#項目属性」関数を使った項目でも，その値は有効になります。 以上の事から，桐は「カウンタ型」のデータが自動決定されるのは， 行のデータが確定された後で，行の再計算が終わった後のようです。 でも，「#項目属性」関数では拾えるけど [項目] では拾えないとか， カウンタ型の値決定と行の評価の順序って，こんなんでいいのでしょうか？
25102	Re:カウンター型	もさく	2004/02/25-20:47
記事番号25075へのコメント マリリンさん >はじめてです。 >表の中で[コード]の項目にカウンター型を使用しています。 >そしてこの[お客様コード]をつくり >項目計算式に#文字列([コード],5)としましたところ >「カウンター型は変換できません」とでます >どうすればいいのでしょうか？ > 私も「カウンター型」にはじめて気づいたとき飛びつきました。 でも単純に項目計算式で使用できないなど私には使い切れないと割り切って 宮城様が述べられているように#直前値([],)+1をもっぱら使用しています。 なぜ項目計算式などに使用できないのか私にはわかりませんが、 皆さんは「カウンター型」をどのように使っておられるのか、また私にはわからない どんな便利な使い方があるのか知りたいなと思っていました。 マリリンさんには何のお役にも立ちませんがチョット書かせて頂きました。
25106	Re:カウンター型	佐田　守弘	2004/02/25-22:09
記事番号25078へのコメント hidetakeさん 　>カウンタ型の値決定と行の評価の順序って，こんなんでいいのでしょうか？ 概ね合っていると思います。 かなり前(確か桐ver.7の頃)ですが、桐のカウンタ型項目について聞いた事がありました。 一言で言うと、桐のカウンタ型はAccessのカウンタ型とは全く仕様がが異なる様です。 Accessのカウンタ型は、文字どおりどこかにカウンタを持っていて、 レコードを追加する度に値をインクリメントしてその値をカウンタ値にセットする様ですね(詳しい事は知りませんが)。 そして、レコードの追加を行った直後にカウンタ型項目の値がセットされると思いました。 これに対して桐のカウンタ型では値をインクリメントするカウンタは持っておらず、 カウンタ型項目のインデックスを持っているそうです。 そして１行のデータが確定した後で、インデックスを使って現在使われている値の最大値+1を求め、 この値をカウンタ型の項目に書き込んでいるとの事でした。 このために、行挿入時にカウンタ型の項目値を決定できず(なぜかは不明)、 １行のレコードの入力が終った後になるとの事でした。 その代わり、Accessでは一度決定したカウンタ型項目値を後から訂正する事はできないけれど、 桐の場合には項目置換で訂正する事ができる利点があるので便利だと思いますが、との事でした。 佐田守弘(KS-00119)
25108	Re:カウンター型	hidetake	2004/02/25-22:18
記事番号25106へのコメント >　>カウンタ型の値決定と行の評価の順序って，こんなんでいいのでしょうか？ >概ね合っていると思います。 これは，こんな仕様で許されて良いのか？と言う投げかけなのですけど！ >その代わり、Accessでは一度決定したカウンタ型項目値を後から訂正する事 >はできないけれど、桐の場合には項目置換で訂正する事ができる利点がある >ので便利だと思いますが、との事でした。 便利ですか？　不便な事が多いように感じますけど！
25112	Re:カウンター型	佐田　守弘	2004/02/25-23:14
記事番号25108へのコメント hidetakeさん 　>これは，こんな仕様で許されて良いのか？と言う投げかけなのですけど！ 意味を取り違えていましたね。 許されて良いかどうかは、私には何とも言えません。 とは言え、行追加した段階でカウンタ型の値が決まってくれたらとは思います。 （不可能ではないと思うのですけどね） 　>便利ですか？　不便な事が多いように感じますけど！ カウンタ型は唯一の値が一度決まったら、金輪際同じ値は２度と出て来ては困るのが本当なのでしょうね。 佐田守弘(KS-00119) ps：昔話ですが (その１)解説記事のサンプルデータ 編)画面図版だと１から始まってますよね。でもサンプルデータに入力すると１からじゃないと読者が困るでしょ。 図版の様に１から始まるようにして下さいよ。 (その２)データに欠番が... 上)欠番があるのはまずいんじゃないの。不都合なデータを隠していると思われよね。 それは私をAccess嫌いにさせるに充分な効果がありました。
25120	Re:カウンター型	hidetake	2004/02/26-07:03
記事番号25112へのコメント >それは私をAccess嫌いにさせるに充分な効果がありました。 これって，Access と直接関係あるのですか？ 欠番が出るというのはどんなシステムでも発生しうる事で サンプルだから無くしたいというのあれば，そうすれば 良いだけのような気がします。 Access でも桐と同じようなやり方をしたいというのであればそうすれば良いのであるし， 桐のように直前値って言うような使い方の場合， 最初に並べ替えを行っておく必要もあるけど，他の DB の場合 DMAX のように簡単に 最大値を取得する方法だってありますし？
25121	Re:カウンター型	hidetake	2004/02/26-07:36
記事番号25112へのコメント >　>これは，こんな仕様で許されて良いのか？と言う投げかけなのですけど！ 私の勝手な想像によると，これはおそらくは共有時のパフォーマンスを 低下させないための妥協点でこうなったような気がします。 桐は全てのテーブルが独立したファイルとなっているが為にファイルのオープンクローズにも 大きなコストを発生させると思いますが，それをできるだけ少なくするために， 実際の行追加時に最終決定する事にしたのでは無いでしょうか？ SQL 的なサーバであれば，行の追加時にサーバ側が処理し決定するので 当然このような仕様になると思いますが，デスクトップデータベースと しては，何かと使いづらい面が多いと私は感じています。 (サーバ側に任せるなら任せるでそんな場合はそれなりの方法もある) 項目計算式などでもカウンタ型の項目が計算式に使えないのも， 先に書いたように値が実際の行が追加される段階で無いと決定されされないから， 使えるようにしてしまうと，その結果が反映されずにユーザの思惑と 違った結果になるからでしょうか？ では，実際の行追加時にカウンタ値が決定した後で，行の再評価をやればいいのでは？ となると，はやりその再計算の発生や遅延によりパフォーマンスの低下や 共有管理情報へのアクセス時間・回数等，この辺を考慮したような気もします？ また，これだったら最初にカウンタ値を決定させても一緒のような気もしますしね？　違うかな？　(^^; で，結局，私は桐のようなデータベースの仕組みやデータの持ち方では カウンタ型って使いづらく，結局はあまり使いたくない？となったりします　(;_;)
25154	Re:カウンター型の使い道	佐田　守弘	2004/02/26-22:08
記事番号25121へのコメント >で，結局，私は桐のようなデータベースの仕組みやデータの持ち方では >カウンタ型って使いづらく，結局はあまり使いたくない？となったりし >ます　(;_;) ほぼ同感です。 この質問の最初の主旨につながる話ですが、私はカウンタ型は、 あくまでも陰に隠れてユニークな値を自動発生させる用途に限るのだろと思っています。 私が使う時は、次の様な原則で扱っています。 1)カウンタ型の項目は、リレーションのための主キー項目としてのみ使う。 （差し当たって使わない場合でも一応[ID]の項目名で持っておく事はあり） 2)作ったカウンタ型の[ID]は、表の上でも非表示にしておく。（自分でも見ない） 3)カウンタ値の値そのものは決して人には見せてはならない。特にDBを理解しない人 には要注意。（やれ欠番があるとか、なぜなのかと、あらぬ文句を付けられるだけ） 4)カウンタ型の値はあくまでも隠れた値であるから、これを計算式に参照する事は始めから考えない。 5)見せるためのIDが必要なら、カウンタ型のIDとは別に、見せかけのIDを別に作る。 そしてこれはリレーションには使わない。 所で、 >サンプルだから無くしたいというのあれば，そうすれば >良いだけのような気がします。 ですが、 サンプルは検証のために入力テストもするし、入力した結果の画面も採取します。 するとテスト入力したためにカウンタ値が進んでしまい、0には戻せないわけです。 0に戻すには、テーブルを作り直すしかないわけですが、設定しているリレーションシップを解除して、 テーブルを削除して同じものを作り、改めてクエリーまで作る必要があるわけで、 作業としてとても大変でした。その意味です。 （作り直しは新しいエラーの元にもなるし） 佐田守弘(KS-00119)
25157	Re:カウンター型の使い道	hidetake	2004/02/26-23:21
記事番号25154へのコメント >>サンプルだから無くしたいというのあれば，そうすれば >>良いだけのような気がします。 >ですが、 >サンプルは検証のために入力テストもするし、入力した結果の画面も採取します。 >するとテスト入力したためにカウンタ値が進んでしまい、0には戻せないわけです。 サンプルだからつじつま合わせも簡単だろうし やり方はいろいろあるでしょうけど，データを 全部消してその状態で最適化をかける事でしょうね！ そしたらカウンタはリセットされるし！ あとはデータを最初から入れ直すか，保存しておいた読み込ますとか？
25159	Re:カウンター型の使い道	佐田　守弘	2004/02/27-00:12
記事番号25157へのコメント hidetakeさん >データを全部消してその状態で最適化をかける事でしょう >ね！　そしたらカウンタはリセットされるし！ 最適化でリセットできるとは知りませんでした。 ありがとうございました。 （10年前に気がついていたら...） 佐田守弘(KS-00119)

戻る