過去の桐井戸端ＢＢＳ　（桐ver.８）
8270 共有で行挿入出来ないのは仕方がないこと？ みすず 2000/10/27-14:17
現在の桐では、共有状態では行挿入できませんが、共有環境化では当然といった仕様なのでしょうか？
たしかに「初期状態の行並びに意味はない」といった考えが基本でしょうが、桐において使う行挿入は、
ただ単に指定したレコードを簡単に複写したといった目的が大半なはずです。
結果的に最後に追加されたとしても、行挿入自体は共有で使える方が良いと思いますがいかがでしょうか？
現在の仕様で共有状態の表編集では、まともな行複写機能が見あたりません。（もし有れば教えてください）
現在では、指定行の左端に合わせ、右クリック→絞り込み_選択行の後、F3二回押し(行追加−直前行)で
行挿入と同様の事が可能ですが、実に面倒です。(桐５互換の場合)

そういった意味では、指定行複写&行追加を簡単にできるような機能があればいいんですが。

8309 Re:共有で行挿入出来ないのは仕方がないこと？ 佐田　守弘 2000/10/29-22:56
記事番号8270へのコメント
みすずさん
詳しくは知りませんが、多分「仕方ない事」なのではないかと思います。

実の所、「行挿入」は桐特有の機能で、Accessなどには行追加はあっても、行挿入はなかったと思います。
おそらく、行追加(最後にデータレコードを追加する)は簡単でも、現在の編集レコードの位置に行追加をするのは、
様々な点で難しさがあるのでしょうね。
桐の場合でも、絞り込みや並べ替えなどが行われていない基本状態でないと行追加は行えません。
これは、そういった状態では、編集行の位置が不明確になりますから、行追加のしようがないという事なのだと思います。

そして、共有で開かれている表では、他のユーザーがどの様な状態でその表を使っているかの保証がないので、
同じ意味で行追加が不可能になる(行追加を行う事ができない)と思います。

●基本状態で目的の順序で並べておきたい
実の所、これは本心ですね。
住所録であれば、索引や並べ替えを使わずとも、名前の読み順で常に並べておきたいところです。
で、それは可能です。というか、自分で並べ替えればよいのです。
方法は簡単で、目的の順序で並べ替えた後、ワーク表に書き出します。
次いで、元の表を全行削除した後、ワーク表から読込みます。
会話処理では間違えやすいので、一括処理ないしはイベントなどで処理するのが良いかと思います。

佐田守弘(KS-00119)
8339 Re:共有で行挿入出来ないのは仕方がないこと？ みすず 2000/10/31-11:26
記事番号8309へのコメント

>方法は簡単で、目的の順序で並べ替えた後、ワーク表に書き出します。
>次いで、元の表を全行削除した後、ワーク表から読込みます。

コメントありがとうございます。
やりたいことは要は共有でソート状態を維持したいだけなんですが、
データを追加するたびに並び替えをしなくてはならないので不便です。
共有でも並び替えをきいた状態にできればいいんですけど
8355 共有で索引が有効にならないのは 佐田　守弘 2000/11/01-01:36
記事番号8339へのコメント
みすずさん
>データを追加するたびに並び替えをしなくてはならないので
>不便です。
>共有でも並び替えをきいた状態にできればいいんですけど
確かに、共有の時に索引が有効にならないのは不便だと思います。
その理由は、「共有で開かれた表-佐田　守弘(10/26-18:33)No.8258」に書いた通りなのですが、簡単にまとめれば、次のようになります。
まず、桐が表を開く時に索引情報を先に読み込み、メモリに記憶します。
これは、その後の目的レコードのあり場所を探す時間を短縮化するためです。
専有の場合には、索引を更新するのは自分しかいないので、メモリ上にある索引は常に最新である事が保証されています。
ところが、共有の場合には他の人がレコード追加などを行って索引が更新される可能性があります(あって当たり前）。
するとメモリに読んでおいた索引情報が正しくないため、これを使って並べ替えを行うとエラーが起きます。

●共有でも索引を使う方法はないのか
もし、共有でも索引を有効にして並べ替えを高速で行う方法がないのかを、考えてみます。
高速検索をするために、索引をメモリに先読みする方法は、上記の理由でだめですね。
ですから、並べ替えをする度にディスクに記録されている索引情報をその度に読み出す必要があると思います。
それ以外の方法は思いつきません。
でも、メモリ上のデータを参照するのと違って、ディスク上のデータを参照するのは、かなり時間がかかる処理になります。

それに索引は結構サイズが大きいのです。
ちなみに索引のサイズは、索引項目に指定した項目値のデータ量とほぼ同じです。
これは索引ありの場合と無しの場合の表サイズを比べてみると分かります。
１レコード追加する度、あるいはスクロールする度に最新の索引を見に行く事が、速度的に果して堪えられるかどうかですね。

索引を読む時間は、表を開く時間とほぼ同じと考えて良いでしょう。
なぜなら、表を開く時に開くまでの時間に行われているのは、索引の読み込みです。
レコードデータは、表示に必要な部分しか読まれませんから、時間的な比率は少ないはずです。

つまり、最新の索引をディスクから参照しようとすると、編集の度に、またスクロールの度に表を開く程の時間が掛る事になります。
多分これには堪えられないのではないかと思います。
また、ネットワークで利用すると、その様な膨大なデータが常にネット上を流れる事になり、
ネットワークにもかなりの負荷をかける事になりそうです。

●索引が更新されるタイミング
共有でも索引は更新されるのですが、レコード値が更新されるタイミングと索引が更新されるタイミングに微妙な違いがあるそうです。
理由は詳しくは分かりませんが、キャッシュの書き戻しのタイミングか、複数ユーザーが更新した索引の整合性を取るためではないかと思います。
つまり、仮に索引を毎回読み直したとしても、索引情報とレコードデータ情報が微妙に食い違うタイミングもあるらしいのです。

●結局は一時的な索引を作る必要がある
自動更新する必要がない索引で良いですから、その時のレコード値で一時的な索引を作る必要がありそうです。
桐ver.5には、自動保守しない整列索引がありました。
で、Windows版からはこれを「並べ替え」と呼ぶ様になりました。

いろいろ考えてみたけど、結局は元の木阿弥で、必要な時に並べ替えを行う(保守しない索引を作る)のが便利、という結果になりそうです。

佐田守弘(KS-00119)
8362 Re:共有で索引が有効にならないのは みすず 2000/11/01-17:51
記事番号8355へのコメント
佐田　守弘さんは No.8355「共有で索引が有効にならないのは」で書きました。

コメントありがとうございます。
共有で索引を実現するには技術的にハードルが高いのですね。
次世代の桐に期待する事にします。
どうもありがとうございます。

戻る