過去の桐井戸端ＢＢＳ　（桐ver.８）
4774 結合表の対象表は他のフォルダの表を指定できないのでしょうか 真太郎 2000/02/20-00:08
結合表の対象表は他のフォルダの表を指定できないのでしょうか？
4777 結合の対象表のフォルダ 佐田　守弘 2000/02/20-02:52
記事番号4774へのコメント

できません。結合対象表は、同じフォルダの中にある表に限られます。これは、Accessでは１つのmdbファイルを
１つのデータベースとみなすのと同様に、桐では１つのフォルダを１つのデータベースとしてみなすと考えて下さい。

もし他のフォルダにある表を結合するのであれば、その表をコピーして来て結合を行って下さい。
そして、結合によって実表更新した場合には、元のフォルダに書き戻すなどの処理も必要になります。
書き戻しはMS-DOSのコマンドを使いますが、桐のファイル複写コマンドでも可能です。

佐田守弘(KS-00119)

4778 補足：結合の対象表のフォルダ 佐田　守弘 2000/02/20-02:57
記事番号4777へのコメント
直前コメントに書き忘れました。
結合表を使う前提として、結合関係と参照整合性の設定がありますが、
これらは同じフォルダないでなければ設定できません。
おそらく、別のドライブやフォルダも許してしまうと、ドライブ構成が異なる場合、
リムーバブルディスクが装着されていないような場合に、
結合関係に不都合を発生する事があるためだと思います。
また、結合関係を設定すると、１つの表を開いても他の表も自動的に開かれます。
この様な関係で、同じフォルダ内にある表でなければ、結合関係や参照整合性の設定ができず、
しいては結合ができないのであろうと思われます。

佐田守弘(KS-00119)
4783 Re:補足：結合の対象表のフォルダ hidetake 2000/02/20-08:36
記事番号4778へのコメント
>この様な関係で、同じフォルダ内にある表でなければ、結合関係や参照整
>合性の設定ができず、しいては結合ができないのであろうと思われます。

これは私は違うと感じております。

別に参照整合性などの管理情報を共有管理情報領域に桐が持っておれば
別にフォルダやドライブがまたがっても管理できたと思いますが、桐は
この辺の情報をそのフォルダ内に保持しています。
REF_DEF.POS , REF_DEF8.TBL (REF_DEF7.TBL)
従って、フォルダやドライブがまたがっても管理しようにもできない
構造になっています。

さらには、桐７と桐８はテーブルについては同一構造で、一応共用も
共用が可能なのですが、管理情報にバージョン番号を持たせているので
共有は成り立たない構造になっています。

以上のことから私は設計上の問題だと感じております。

Access では 2.0 で通常使っていても Jet 経由で違うバージョンでも
リンクし使うこともできます。
また、リンクは通常、ドライブ名を含んだリンクがデフォルトですが、
UNC でも可能です。
リンクに UNC を使えば peer to peer でもドライブやフォルダの違い
を越え違う PC 上でも簡単に共有することが可能です。

Access なんかでは何年も前からこのような事が簡単に可能だったにも
関わらず、桐はそのような事は何も考えて作られていないので、我々は
重い十字架を背負い使って行かねばなりません。それが信者の宿命です。

4784 Re:別フォルダでもＯＫ？ bonito 2000/02/20-13:54
記事番号4783へのコメント

>我々は重い十字架を背負い使って行かねばなりません。
>それが信者の宿命です。

なるほど...、信者ですか...。
私は、隠れ「桐・知・短」なんて...(-_-;)

ところで、随分昔(DOS時代)の情報で、TBLとそれを表示
する為のFRMは同じディレクリィに置かなければならない
と、つい最近まで思い込んでいましたが、サブフォーム
を作っている最中偶然、その制限が取り除かれている事に
気づきました。
これは、いつからで、そしてアナウンスされたのでしょうか？
それとも制限そのものが(私の勘違いで)、最初からなかった
んでしょうか？

結合も、当然そのうち別フォルダでもＯＫになるとは
思いますが、その前にクリアすべき問題の方が多いような
気がしますね。


4789 Re:別フォルダでもＯＫ？ hidetake 2000/02/20-15:43
記事番号4784へのコメント
>ところで、随分昔(DOS時代)の情報で、TBLとそれを表示
>する為のFRMは同じディレクリィに置かなければならない
>と、つい最近まで思い込んでいましたが、サブフォーム
>を作っている最中偶然、その制限が取り除かれている事に
>気づきました。
>これは、いつからで、そしてアナウンスされたのでしょうか？
>それとも制限そのものが(私の勘違いで)、最初からなかった
>んでしょうか？

これは作るときの制限で、１度作ってしまえば別ディレクトリ
にあるフォームでも利用できました。

Windows 版になってからのことは知りませんでした。
　
　
>結合も、当然そのうち別フォルダでもＯＫになるとは
>思いますが、その前にクリアすべき問題の方が多いような
>気がしますね。

これもいつのことになるのか...

もしやろうとすると、相当な作り直しになると思います。
そして、今の桐は他の DB からすれば信じられないいろいろな制限が数多くあります。
それを今の桐をベースに小手先の改良でしのぐのか、あるいは根本から作り直すのか、
ユーザー側の決断も必要なのかも知れません。
本当は Windows版を作るとき、DOS の事など忘れ、根本から作り直して欲しかった！

これから桐がどこへ行くかなど我々にはまるで見えない世界です。

信者は周りの世界には目を背け、ただ桐を信じて突き進むしかありません。
知ったら最期、煩悩の日々と、行く末には＊＊がまっております。


4793 Re:別フォルダでもＯＫ？ 佐田　守弘 2000/02/20-22:51
記事番号4784へのコメント
bonitoさん、hidetakeさん
結合対象表が１つのフォルダになければならないか、別フォルダの表も許すかは、hidetakeさんが#4783でも
書いている通り、設計上の問題だと思います。
おそらくこの制限を外す事自体は、システム的にはそれ程難しい話ではないと考えます。
ただしそれが一般的な桐ユーザーにとって、本当に幸せかどうかは別問題なのでは。以下は私の考えです。
①結合関係の定義ファイル(ref_def.tbl)を複数持つ必要がでてくる
現在は、フォルダ単位で結合表を定義するから、一般ユーザーはref_def.tblの事を考える必要がありませんが、
フォルダをまたがって結合関係を定義するとしたら、このファイルをどこに置くか、異なるファイル群での結合関係を定義
する際に、別々のファイル名を付けるかなど、一般ユーザーには煩雑な新しい問題がでてきます。
②データのバックアップやデータ交換時に
このファイルを置くとしたら、桐のシステムフォルダの中かその直下になると思います。
データを別メディアにコピーする際に、この情報も含めてコピーする必要が生じます。
もちろん、バッチファイルや専用のバックアップコマンドを自由自在に作れる上級ユーザーであれば、
そういった煩わしさは感じないと思いますが。
③結合対象表の指定
結合対象表を指定する際に、同じフォルダにあれば指定は簡単ですが、いちいちフォルダを選ぶのは、
結構面倒なものです。まあ、大した話ではないですが。
④リムーバブルメディアが指定された場合
別のフォルダ別のドライブの表の結合を許すとすると、リムーバブルメディアにある表も指定できる事になります。
（できなければおかしい。リムーバブルメディアの読み書きを最初から禁止するなら別です）
もし、そのメディアが抜かれていたとしたら、参照整合性が破綻します。なぜなら、参照整合性を設定した表は、
１つの表を単独で開いても、他の表が自動的に開かれ、参照整合性の保守が行われるためです。
⑤ドライブ構成の異なるパソコンでのデータの利用
HDの場合でも同じです。もし２台のパソコンでデータをオフライン的に共有しようとしたら、同じドライブ構成、フォルダ
構成にしておき、常にファイルのシンクロナイズを保つ必要がでます。
「それが常識です！」と言う事が、果たして全てのユーザーに理解できるかどうか、やや疑問が残ります。

● Accessではどうか
Accessの最新事情は詳しくありませんが、hidetakeさんが書かれている
>リンクに UNC を使えば peer to peer でもドライブやフォルダの違い
>を越え違う PC 上でも簡単に共有することが可能です。

との事ですが、これはファイルの共有ができる事であって、クエリーの対象に他のmdbの中のテーブルが指定できる
事とは違うのではないかと思うのですが。クエリーの対象は、１つのmdbファイルの中にあるテーブルに限られるので
はないでしょうか。

なお、桐で他のフォルダにある表を結合対象表としたいなら、同じ表を目的フォルダの中に作り、他のフォルダにある
表から結合直前に読み込みを行う事が便利かも知れません。
一括処理その他で、自動的に行う事ができるのではないかと思います。
要するにAccessで言うインポートに等しい事を行えば良いわけです。

● 他のフォルダにある表の結合は実現するか
上記の理由で、絶対に実現しないと断言します。実現されては困ります。
もしその様な事を管理工学が考えたとしたら、私は猛反対します。
一般ユーザーに余計な精神的な負担を強いる機能ですから。
まあ、もし実現させるとしても、非公開機能に留めてもらわないと、困るのではないでしょうか。

佐田守弘(KS-00119)

4799 Re:別フォルダでもＯＫ？ bonito 2000/02/21-04:53
記事番号4793へのコメント
佐田先生からコメントを頂きましたので、過剰な反応とは取られないだろう、という楽観的な推測のもとにコメント
いたしますが...。（もっとも、hidetakeさんや佐田先生と、私とではレベルが違いすぎるので、私の場合大人の話に
首を突っ込む子供みたいなもんですが...。）

>一般ユーザーに余計な精神的な負担を強いる機能ですから。

私はどちらかというと今の「結合」の設計（？）の方が桐らしく(？)ない、余計な負担モノだと思っています。
参照整合性なんか設定しなくてもいいじゃん、ただしその場合は自動的に実表の更新は出来ませんよ。
（DOS時代の機能拡張版？）
主キーと外部キーを結合条件に指定すれば、実表の更新するがデフォルトになりますよ。　・・・ではいけませんか。

システム内部の事はわかりませんが、表面(？)はその方が、少なくとも私には分かりやすいンですけど...。


4800 Re:∧すみません訂正します bonito 2000/02/21-06:16
記事番号4799へのコメント
訂正します。

>参照整合性なんか設定しなくてもいいじゃん、ただしその場合は
>自動的に実表の更新は出来ませんよ。（DOS時代の機能拡張版？）
>主キーと外部キーを結合条件に指定すれば、実表の更新するが
>デフォルトになりますよ。　・・・ではいけませんか。

やっぱり、大体、そうなっていました　m(__)m

私としては、
<4784>
>>TBLとそれを表示する為のFRMは同じディレクリィに置かなければ
>>ならないと、つい最近まで思い込んでいましたが、

<4789>---hidetakeさん、ありがとうございました---
>これは作るときの制限で、１度作ってしまえば別ディレクトリ
>にあるフォームでも利用できました。

で勘違いは恐ろしいと・・・、だとすれば失礼ながら・・・、

<4778>
>結合表を使う前提として、結合関係と参照整合性の設定がありますが、
>これらは同じフォルダないでなければ設定できません。
>また、結合関係を設定すると、１つの表を開いても他の表も自動的に開かれます。

はマズイのではないか？（誤解を招きかねない表現だと...）
　1.参照整合性を設定しなくても、結合は出来る　（ホントです）
　2.三行目の結合関係は、参照整合性と記すべき　(別物だから)
結合と参照整合性は常にワンセット物ではなく別の概念である（から勘違いしないでね）

というコメントをしようと、念の為ちょっと確認作業を行ったら、確認作業に失敗...(;_;)
「おかしいな～、確かこの前参照整合性を設定してない結合表をつくった筈なのに
やっぱり、佐田先生の言うとおりなのかなぁ」と疑心暗鬼におちいり<4799>の発言になった次第です。
何の事はない、心配した勘違い第１号は自分自身だったというおそまつ...。

又ゴミを増やしました、済みません　>　幅田さま

ｐｓ.
　であるから、参照整合性はともかく、結合表に関しては（参照整合性なしなら）
　TBLとWFMの関係のように、別フォルダにあるものを結合させてもらっても別に
　かまわないような...。

4802 Re:別フォルダでもＯＫ？ hidetake 2000/02/21-07:19
記事番号4793へのコメント
なんとコメントして良いことか...

疲れるだけだ...
4803 Re:∧すみません訂正します hidetake 2000/02/21-08:27
記事番号4800へのコメント
bonito さん、考え方はいろいろあると思います。

そして小手先の改造であれば、少しは対応できるかも知れません。
でも、そこには更なる制限が発生すると思います。

私は桐 Ver7 になり Windows版をまじめに使いだした時、NIFTY にも書いたのですが、今の時代というか、
これからの時代、TBL や WFM や RPT や XVW が１つ１つのファイル構造で良いのかと言う疑問をまず持ちました。
これから、桐が発展する上で、一番の制限になるのでは思いました。

ファイルを個別に持っていると、ファイルアクセスやロックなど、全て OS の配下にあり、その制限を受けることになります。
複数ファイルの読み書きスピードやキャッシングに及びまで制限が出てきます。

他の OS に移植するにしても、そのファイルアクセス構造に左右され、ただ単純に移すこともできなくなる場合も
出てくると思います。

今どきの DB でファイル単位でファイルを持っている
のは何があるのでしょうか？
例えば、大型の DB システムや それを動かす OS は、RAW モードと言うモードまであり、OS のファイルアクセスに
依存しない、DB 自体がデスクアクセスを行い、スピードを上げるような仕組みまであるそうです。
今まで、このモードを持たなかった Linux も Oracleなどの DB に対応するため、次の版から対応するとも読みました。

桐とは用途が違うので一概に比較できませんし、そこまで対応する必要は無いと思いますが、何も旧態依然
基本構造を改良せず、基礎工事をやり直さずに、上物だけを張り付けていても、キシミが出てくるのは当然
の事だと思います。

共有関係にイベントしかり、オブジェクトに致っては本当にそれでもオブジェクト？
なんでいつでも参照や設定ができないの？(なんで操作とか面倒な手続きが必要なのかと言う意味です)

その様な意味まで含めて、大改造が必要だと私自身は思っております。

4807 Access のアタッチテーブルとクエリー hidetake 2000/02/22-00:16
記事番号4802へのコメント
Access をご存じない方のために説明しておきますが、桐で言うところの結合や選択、それに置換などは Access
ではクエリーを使います。
また、Access の場合、データは正規化して持つように設計されるので多くの場合、テーブルを直接操作することは無く、
クエリーされた結果(ダイナセットと言う)をフォームなどで編集することになります。
更には、桐で入力時に表示させるような表引きも、フォーム上のコンボボックスにクエリービルダ等で作成した
SQLステートメントを記述したクエリーを使います。

要するにクエリーが Access の基本であり命であるわけです。
そのようなクエリーに外部データベース(Jet 経由の Access に dBASE 他、それに ODBC 経由 SQLServer や Oracle　他)
を使えないとなると、データとしては全く役に立たないと言うことです。
もちろん、そのような事はあり得ないことで、Access の特徴として、外部データをリンク(2.0の時代はアッタチと言った)
する事で全く自分の持つテーブルのように扱える事があげられます。
私は 2.0 以降しか知りませんが、当然 1.0 (日本語版が出たのは1.1)
から備えていた機能だと思います。
詳しくはマニュアルにありますが、面倒なので次のコメントにヘルプファイルの１部を引用します。

さらに後のバージョンでは自分自身の MDB をコード部分とデータ部分を分けるために
「データ分割ウイザード」まで追加されています。
と言うことで、クエリーを理解せずして Access の理解などあり得ません。
また、データの保守の面やスピードの確保など、いろいろ使って
いけば、データの分割なども当然のように行われます。

最期に、私は何も Access は最高だ、Access に移ればみんなが幸せに
なれるなんて事を申しているわけではありません。単純にそれで済め
ば私は完全に移行しているでしょう。桐には桐の良いこところはあり
ますし、私の場合は私だけでは済まず他の信徒を引き連れております。

ただ、桐は Access をある程度目指して来たはずですし、Access は
1992年頃からは存在していると思います。2.0 にしたって 1995年の
ハズですから、桐５が出て１年もしないうちにはあったと思います。
そんな目標となるような相手が随分前からあったにも関わらず、桐は
それを追い越すどころか、他の DB では問題にもならないような部分
の制限があまりに多すぎると思います。コーディングに悩まされるの
は聞いたり、努力すれば解決できますが、仕様上の問題はわれわれの
努力だけ克服できないし、目標のためでは無く、それを回避するだけ
の無駄な努力に感じます。また、桐の中だけの発想では桐はいつまで
も良くならないと思います。


4808 Re:Access のアタッチテーブルとクエリー hidetake 2000/02/22-00:17
記事番号4807へのコメント
■Access 2.0 のヘルプより...
>-----------------------------------------------
>Access オブジェクトのインポートとアタッチ
>-----------------------------------------------
>Access のデータベースは一度に 1 つしか開くことができませんが、
>他のデータベースのテーブルをアタッチすることによって、カレント
>データベースと同じように使うことができます。また、他の Access
>データベースで作成したデータベースオブジェクトをカレントデータ
>ベースにインポートすることもできます。
>
>注意
>同じ Access データベースから2つのテーブルをアタッチする場合は、
>元のデータベースでテーブル間に設定されていたリレーションシップ
>が受け継がれます。
　
>-----------------------------------------------
クエリー
>-----------------------------------------------
>テーブルからデータを抽出するための問い合わせ、または選択した
>データに対して処理を実行するための要求を指します。Access では
>次のクエリーを作成して実行することができます。
>
>選択クエリー：クエリーを作成して実行すると、テーブルから抽出
>　　　　　　　されたデータがダイナセットに表示されます。選択
>　　　　　　　クエリーでは、データの変更は行われません。基に
>　　　　　　　なるテーブルのデータは、ダイナセットが表示され
>　　　　　　　た後でも表示や変更が可能です。
>アクション クエリー：データの変更や移動を行います。アクション
>　　　　　　　クエリーには、追加クエリー、削除クエリー、テー
>　　　　　　　ブル作成クエリー、更新クエリーがあります。
>クロス集計クエリー：行と列の値を集計します。
>パラメータ クエリー：独立した種類のクエリーではなく、他のクエ
>　　　　　　　リーを柔軟に使うためのクエリーです。実行するたび
>　　　　　　　に異なる抽出条件が指定できます。
>SQL クエリー：SQL ビューで SQL ステートメントを記述することに
>　　　　　　　よってのみ作成できます。SQL クエリーには、ユニ
>　　　　　　　オンクエリー、パススルー クエリー、データ定義
>　　　　　　　クエリーがあります。
　
>-----------------------------------------------
>クエリーでのテーブルの追加と削除
>-----------------------------------------------
>注意
>他のデータベース、または他のアプリケーションのテーブルをクエリー
>に追加するときは、先に、そのテーブルをデータベースにアタッチして
>ください。
　
■Access 97 のヘルプより...
>--------------------------------------------------------
>既存のデータベースをデータとオブジェクトに分割する
>--------------------------------------------------------
>この操作でデータベースを 2 つのファイルに分割します。
>1つのファイルにテーブルを保存し、もう 1 つのファイルにクエリー、
>フォーム、レポート、マクロ、およびモジュールを保存します。このよう
>にすると、ユーザーがフォーム、レポート、および他のオブジェクトを
>変更しても、ネットワーク上に単一のデータ ソースを維持できます。


4811 Re:Access のアタッチテーブルとクエリー よしとも 2000/02/22-02:18
記事番号4807へのコメント
いつもおせわになってます．
ずーっとＲＯＭを決め込んでましたが，ちょっとつらさが
臨界点を超えたのでつっこみを入れさせてもらいます．



hidetakeさんは No.4807「Access のアタッチテーブルとクエリー」で書きました
。

>ただ、桐は Access をある程度目指して来たはずですし、Access は
>1992年頃からは存在していると思います。2.0 にしたって 1995年の
>ハズですから、桐５が出て１年もしないうちにはあったと思います。
>そんな目標となるような相手が随分前からあったにも関わらず、桐は
>それを追い越すどころか、他の DB では問題にもならないような部分
>の制限があまりに多すぎると思います。コーディングに悩まされるの
>は聞いたり、努力すれば解決できますが、仕様上の問題はわれわれの
>努力だけ克服できないし、目標のためでは無く、それを回避するだけ
>の無駄な努力に感じます。また、桐の中だけの発想では桐はいつまで
>も良くならないと思います。
>
>

うん，桐がシステム開発ツールだとすれば上記の発言は本当かも．
でも桐はシステム開発ツールなの？
んでもってＫ３はそのようはプロダクトを販売している会社なの？


桐ってQuik&Dirty（とゆーとperlですね）なデータ処理ツール
だったと思ってたので，そーゆーことが書かれてるの見ると
不思議な気持ち．つまり２０％の努力で８０％の問題を解決する
能力があるなら，それは依然として桐なんだ，と思ってますので．

そーゆーわけで，わたしゃＤＢかどうかすら桐の本質ではないと
確信しております（とは言い過ぎか？）．てなもんで，結合の
スペックで，およそＤＢと名のつくものなら，的な話が展開され
ているのはなかなかミゼラブルな気持ち．
いや，それが一般教養の話で，しかもサロン的に行われてるんなら，
おお啓蒙だなあ，と思えなくもないんだけど，それが無いからＮＧ
なんだ，みたいな話はすんごく有害．われわれ（とゆうのは私と私
かもしんないけど）が欲してるのは個別の切実な問題に対する解で
あって，それにたどり着くショートカットとして桐が機能かどうか
だけが問題なの．

で，もっとゆうと，ここの掲示板は殆どの人はそのような認識の
もとに，あの時はこうするでしょう，この時はああするでしょう，
とノウハウを共有しあってみんなで幸せになろうとしてるのだなあ，
美しいことよ，と思ってたんですが，どうもhidetakeさんは
そーゆースタンスではないようですね．
あなたの書いてることは一貫して，オレの知ってるすげー話を聞い
てくれ，だけであって，おまけに興が向くと延々桐と関係の無い話題を
を一人で書きこみつづける．もう勘弁してくれ，って感じなんですが，
ほんともう勘弁してくれないでしょうか．

あと，冷静な話をしておくと，システム開発をなさって生計をたてて
おられるようですが，もう少しクールにツールの選択をなさるべき
でしょう．
なんとなれば桐はシステム開発ツールには向いてないし，これからも
きっと向かないことが予測されるからです．木に竹を接ぐようなはなし
をして，なんでできないんだ，とここに書きこみをしていても詮方無い
だけですんで，そのようは御時間があるのでしたら，他のツールへの
移行に割かれたほうが有意義かと存じます．
4813 Re:Access のアタッチテーブルとクエリー hidetake 2000/02/22-07:40
記事番号4811へのコメント
よしともさん、はじめまして _o_

よしもとさんは、そのように受け取られたのですね。
残念だけど、そうとられたものしかたありませんね。
でもありがたいです、こんなつっこみをしてくれる方
がいて...

一般の方が書く内容にそれほど深くこだわったことは
無いと思いますが、プロフェショナルなかたの発言に
明らかな間違いがあれば、それが当然だと一般の方が
信じてはいけないと、無用な部分まで深入りする傾向
はありました。

桐が、開発ツールであるのか無いのか、私にはどうか
わかりませんが、いろいろな使われ方がされていると
思います。私も桐を10年以上使い続けて、愛着はあり
ますし、使い続ける以上、少しでも良くなって欲しい
という願いはあります。

そして、他の環境にいけばと言うことですが、私には
簡単にそれが出来ない事情があります。
別にここに書くべき内容でも無いですし、単純にお金
に関わる問題でもありません。

私の書き込みは再生不可能なゴミに過ぎなかったよう
ね、残念ですが...

4825 Re:別フォルダでもＯＫ？ WingBoy 2000/02/22-21:04
記事番号4793へのコメント
>事とは違うのではないかと思うのですが。クエリーの対象は、１つのmdbファイルの中にあるテーブルに限られるので
>はないでしょうか。
>

　Accessの場合は「テーブルのリンク」というのがありまして、他のmdbのテーブルに
リンクを張ってクエリーを作ることができますが・・・。

戻る