桐からAccess、Accessから桐？

過去の桐井戸端ＢＢＳ　（桐談義・その他）

499	桐からAccess、Accessから桐？	ikjun	1998/11/1-23:19
みなさんはじめまして！わたしは元桐ユーザー（今もたまに使う）です。Ver2からVer5まで使ってました。その後みなさんも知っているように、 Win版の桐がなかなかでてこないのでDBProなども使ってみたのですが、プログラム部分がどうも馴染めず、しかたないので検討の結果、Accessを使用してます。一応、Accessもある程度使えるようになったのですが、いまでも、桐は使いやすかったなあと思ってます。そこで、桐Ver7.1を再検討しているところなんですが、いくつか、いまいちよくわからないところがあります。そこでお聞きしたいことを列記します。もし良ければお答えいただけませんでしょうか？１．排他制御はどの程度までできるのか？実はAccessの排他制御はきわめて不完全なもので、ページ単位のロック（つまり、ロックしたいレコードの周辺２ｋバイトをロックしてしまう。）しかできません。桐はレコード単位の排他制御ができると管理工学のWeb Pageに書いてありました。それであればそれだけでAccessから移行する十分な理由になります。でも実際はどうなんでしょう？２．一括処理のプログラム構造はどうなったか？一括処理は確かに日本語表記で、日本人としては、わかりやすいのですが、プログラム構造としてはVbの方がはるかに進んでいたと思います。（Dosの限られたメモリの中では、しかたなかったことでしょうが？）具体的にいうと、 FunctionやSubなどのユーザー定義関数の概念がない。ほかの一括処理に処理を移した場合、元の一括処理に戻るためには変数で場所を記憶させるなどの処理が必要でした。これらのことは、短いプログラムであればたいした問題ではないのですが、少し大きなプログラムを作ると大問題になります。桐からAccessに移った理由にこれも多少関係しています。イベントドリブン（つまり、アイコンにプログラムを張り付ける方式）だと、それほど、長いプログラムを書く必要がありませんので、まあ運用でなんとかなるのでしょうが、ちょっと気になる部分です。桐Ver7ではどうなったのでしょうか？あとは、長所、短所いろいろあると思いますが、管理工学の製品は桐、松などを使用した経験上、信頼性が高いと思いますので、上記ことがどうなっているのか？または将来どうなるのか？といったところ次第でもう一度桐をメインにしようかと思ってます。それと、ちょっと気になったのですが、この掲示板の中で桐はアマチュアエンドユーザー向けで、Accessはプロ向けで高機能というようなことを書かれたのを目にしたのですが、それはちょっと違うのではないかという気がします。 Aceessも基本的にはアマチュアエンドユーザー向けでしかないと思います。「」の中はあるWeb Pageで見かけた記述です。つまり、Accessは米国では桐と同じか、それ以下の存在でしかないようです。英語表記で、機能が整理されずに山盛りになっているのでそうはみえませんが？「Accessのみで重要なシステムを構築する勇気のある方々は、世界中探しても日本だけにしかいないと思います。ちなみに、米国ではプロフェッショナルは、Microsoftのデータベースでも、XBASE系の FoxPro を使うことが多いようです。ちょっと前までは、Accessはシロートがクリスマスカードを出すのに使うものという認識だったのです。」実はアクセスの会議室（当然、わたしなどは足下にも及ばない人がうじゃうじゃいる）などに時々おじゃまするのですが、Accessの達人のほぼ一致した意見が、本格的なシステムはAccessだけではできない。OracleやMS-Sqlを使用しなければいけないということです。主な理由は排他制御の不完全さなんですが、Accessを覚えるだけでアップアップのわたしとしては、OracleやMS-Sqlを覚えなければならないと思うと、ゾッとします。お金も相当かかります。小さなシステム（データ量が知れているという意味）ばかり組んでいる私としては、安く、短時間で組める方法を常に求めているのですが、そうはいっても今時 Lan環境で問題があるのは問題外です。そこで、桐よもう一度と思うのですが・・・・・・・・・・・
500	Re:	MIT	1998/11/2-10:59
記事番号499へのコメント >　１．排他制御はどの程度までできるのか？排他制御は１行（レコード）単位でロックできます。つまり、アクセスなどの先に終わったもの優先ではなく、先に始めたもの優先ですね。私などはレコードロックはマルチユーザーシステムでの必要条件だと思いますので当然の機能かと思います。桐Ｖ７で問題となるのは、このレコードロックを効かせるための表（テーブル）の開きかたをした時（共有更新で開く）です。データベースシステムの基幹機能とも言えるインデックス（索引）がこの場合は機能しないのでデータ量によっては検索などが、かなり遅くなります。また、共有更新で開く表は「表引き」できません。これは「表引き」される表を桐が「参照」で開くからです。結論としてレコードロック機能を有効とし、高速検索を望むのであればおそらく数千件程度のデータ量が対象になると思います。 >　２．一括処理のプログラム構造はどうなったか？基本的にＤＯＳ桐と同じだと思います。いわゆるイベントドリブン的なものではなく例えばコマンドボタンをクリックするとそのコマンドボタンのオブジェクト名を返すので、それにより条件分岐する記述になります。フォームでのイベント取得は基本的にはオブジェクト会話コマンドで行うことになるようです。オブジェクトという言葉は使われていますがオブジェクトのプロパティ（属性）の制御は貧弱です。まだまだ未整備といったところでしょうか。手続きコマンドが拡張され、他の一括処理から手続きのみを参照できるようになりました。アクセスのモジュールに近いものでユーザー定義関数的な使い方ができます。Ｗｉｎｄｏｗｓのプログラムがだいたいそうであるようにネスト構造は処理速度が低下しています。繰り返しコマンドなどは記述によっては動きが見て取れるほど遅くなります。一括処理の悪口ばかり書いてしまいましたが、日本語プログラミング環境として一括処理はすばらしいと思います。この世から消えてほしくないものです。ＭＩＴ
502	Re:	ikjun	1998/11/2-22:24
記事番号500へのコメントありがとうございます。桐にもこういった会議室（？）があってMITさんのような人がいるだけでもポイント高いですね。 >排他制御は１行（レコード）単位でロックできます。つまり、アクセスなどの先に終 >わったもの優先ではなく、先に始めたもの優先ですね。 >私などはレコードロックはマルチユーザーシステムでの必要条件だと思いますので >当然の機能かと思います。その当然の機能がAccessにはなくて、その事実を知ったときは唖然としました。 >桐Ｖ７で問題となるのは、このレコードロックを効かせるための表（テーブル）の >開きかたをした時（共有更新で開く）です。 >データベースシステムの基幹機能とも言えるインデックス（索引）がこの場合は >機能しないのでデータ量によっては検索などが、かなり遅くなります。 >また、共有更新で開く表は「表引き」できません。これは「表引き」される表を桐が >「参照」で開くからです。それでも無いよりはずっとましですね。 >結論としてレコードロック機能を有効とし、高速検索を望むのであればおそらく >数千件程度のデータ量が対象になると思います。データーを分割するようにすれば、十分です。 >基本的にＤＯＳ桐と同じだと思います。いわゆるイベントドリブン的なものではなく >例えばコマンドボタンをクリックするとそのコマンドボタンのオブジェクト名を >返すので、それにより条件分岐する記述になります。 >フォームでのイベント取得は基本的にはオブジェクト会話コマンドで行うことに >なるようです。ちょっとがっかりですけど、逆にＤＯＳ桐からは移行しやすいでしょうね。 >オブジェクトという言葉は使われていますがオブジェクトのプロパティ（属性）の >制御は貧弱です。まだまだ未整備といったところでしょうか。 VBは逆に多すぎて、わけがわからないところがあります。 >手続きコマンドが拡張され、他の一括処理から手続きのみを参照できるようになりま >した。アクセスのモジュールに近いものでユーザー定義関数的な使い方ができます。これは大きな進歩ですね。ぐっと使いやすくなります。 >Ｗｉｎｄｏｗｓのプログラムがだいたいそうであるようにネスト構造は処理速度が >低下しています。繰り返しコマンドなどは記述によっては動きが見て取れるほど >遅くなります。インタプリタで動いてれば仕方ないこと？ >一括処理の悪口ばかり書いてしまいましたが、日本語プログラミング環境として >一括処理はすばらしいと思います。この世から消えてほしくないものです。そうですね。やはり、日本人は日本語ですかね。
505	Re:	MIT	1998/11/3-16:57
記事番号502へのコメント >その当然の機能がAccessにはなくて、その事実を知ったときは唖然としました。私も唖然としました。ＭＳのサポート担当者に「そういう仕様です」とアッサリ言われてＶｉｓｕａｌｄＢＡＳＥを使った経験があります。 >それでも無いよりはずっとましですね。その通りですね。ＤＯＳ桐時代、すでにレコードロック版試作品があったそうですが販売しても良かったと思います。サポートが大変なので見送ったのかもしれません。 >データーを分割するようにすれば、十分です。貴殿は要領を心得ていらっしゃいますね。おっしゃる通りで実は現在、桐Ｖ７のみで開発中のマルチユーザーシステムで本来１つの表を、更新する可能性の有無で2つに分けて更新処理の高速化を図っています。 >ちょっとがっかりですけど、逆にＤＯＳ桐からは移行しやすいでしょうね。イベントドリブンでは、ある処理を実行中に他のイベントを発生させないような細工が必要になることがありますが、それらが全く必要ないところがメリット？でしょうか。一括処理では頭に浮かぶ物語記述で良いわけですから。 >VBは逆に多すぎて、わけがわからないところがあります。何人のプログラマが携わっているのか知りませんが、アクセスなどでも流れがガラッと変わるところがありますね。アクセスをさわり出したころデータソースでソートしてもレポートでは順番がバラバラになって出力される原因がわかりませんでした。 >これは大きな進歩ですね。ぐっと使いやすくなります。これから道具箱に貯めていこうと思っています。 >インタプリンタで動いてれば仕方ないこと？ＤＯＳ桐ではそれを感じさせない速さでしたので、同じ調子で書いているとイライラします。 >そうですね。やはり、日本人は日本語ですかね。日本語、特に漢字は1文字で意味を持っています。つまり欧米の文字に比べて記述量は少なくできるはずです。世界的にはユニークなジャンルになってしまう一括処理ですが我が国では標準になっても良いとおもうのですが．．
506	Re:	幅田	1998/11/3-18:25
記事番号499へのコメント ikjunさん、こんにちは >管理工学の製品は桐、松などを使用した経験上、信頼性が高いと思います同感です。ただし、DOSの頃のお話ですね。どうも、WindowsというＯＳ自体が不安定では、その上にのっかる桐がいくら完全でもどうしようもない部分もあるのでは？と思ってしまいます。まあ、管理工学はそれにもめげず、できるだけ信頼性を高めようとしている努力は感じられますが・・・ >「Accessのみで重要なシステムを構築する勇気のある方々は、世界中探しても日 >本だけにしかいないと思います。ちなみに、米国ではプロフェッショナルは、 >Microsoftのデータベースでも、XBASE系の FoxPro を使うことが多いようです。 >ちょっと前までは、Accessはシロートがクリスマスカードを出すのに使うものと >いう認識だったのです。」 > このようなお話は私も聞いたことがあります。なぜか日本ではVisualFOXProが売られていないそうで、だからAccessということになったんでしょうか？マイクロソフトの戦略でしょうか？それとも単に日本語版が開発できなかっただけなんでしょうか？アメリカではAccessはあまり使われておらず、マイクロソフトもそのうちAccessを切り捨ててしまうかもしれないというお話も聞きました。エクセルのデータベース機能が高まればありうる話かも？いつかどこかで書いたことですが、Accessか桐かというのは、ある程度のシステムを構築できる人のお話であって、もっと末端のエンドユーザーにとっては、エクセルか桐かというお話があってもいいのではないかと思うのです。エクセルの貧弱なデータベース機能に不満を持ったとき、その人はやはりAccessを使うのでしょうか？とっつきにくいAccessを使うより、桐の方がずっと簡単に高度なデータベース処理ができるということを、エクセルユーザーに知って欲しいと思います。あっ、話がそれてすみません。
507	Re:	ikjun	1998/11/3-18:31
記事番号505へのコメント＞ＶｉｓｕａｌｄＢＡＳＥを使った経験があります。私はdbaseII->dbaseIII->QUICK SILVER ->桐->Accessといった遍歴を重ねてきました。あとdbMAGICも併用して使いました。高くて不安定だけど簡単なプログラムなら非常に使いやすかった。結局、QUICK SILVER(dBaseのクローン）のWIN版の開発が異様に遅く、バージョンアップのお金は払ったにも関わらず、一回も使用しませんでした。 Visualdbaseも、同じようなものに別料金払う気がしなくて使いませんでした。＞貴殿は要領を心得ていらっしゃいますね。ありがとうございます。＞おっしゃる通りで実は現在、桐Ｖ７のみで＞開発中のマルチユーザーシステムで本来１つの表を、更新する可能性の有無で2つに＞分けて更新処理の高速化を図っています。業務にもよりますが、それで対処できる場合が多いでしょうね。管理工学の一層の努力は期待したいですが！＞イベントドリブンでは、ある処理を実行中に他のイベントを発生させないような細工＞が必要になることがありますが、それらが全く必要ないところがメリット？でしょうか。＞一括処理では頭に浮かぶ物語記述で良いわけですから。なるほど、イベントドリブンが必ずしも最上とは限らないのですね。＞これから道具箱に貯めていこうと思っています。これが、たまればたまるほど、財産になりますね。開発のスピードもアップしますし！＞ＤＯＳ桐ではそれを感じさせない速さでした確かに、ＤＯＳ桐の完成度の高さはすごいものがありました。早さもそうですが、バグが非常に少なく、環境によっては動かないときもありましたが、環境を整えれば、途中で止まるようなことは少なかった。売れ筋のソフトでハングアップするソフトの多いこと多いこと！なんだかんだいっても、管理工学の製品は完成度が高い。（そのぶん、頑固で流行に乗り遅れがちですが！）桐Ver7.1がどのくらいの完成度なのか使ってみないとわからないけれど、ハングアップしないというだけでも、どれだけありがたいか？＞日本語、特に漢字は1文字で意味を持っています。つまり欧米の文字に比べて記述量は＞少なくできるはずです。世界的にはユニークなジャンルになってしまう一括処理ですが＞我が国では標準になっても良いとおもうのですが．．世界標準というのも捨てがたいものがありますが、桐の一括処理を見ているとCOBOLなどのソースを英語圏の人間が見ると、こんな感じに見えるんだろうなあと思います。ところで、桐にはメーリングリストってないのでしょうか？ここが不満というのではなくそっちの方が便利なこともあるので！
508	Re:	ikjun	1998/11/3-20:05
記事番号506へのコメント >ikjunさん、こんにちははじめまして、Web管理者自らとは光栄です！ >どうも、WindowsというＯＳ自体が不安定では、その上にのっかる桐がいくら >完全でもどうしようもない部分もあるのでは？ >と思ってしまいます。 WinNT上ではどうなんでしょうか。わたしはNT派です。なんならlinux用の桐を開発してくれれば・・・・・・（ちょっと無理か・・・） >なぜか日本ではVisualFOXProが売られていないそうで、だからAccessということに >なったんでしょうか？わたしは昔から、データベース中心でコンピュータを使ってますので、Win3.1がでた当たりから、いろんなデータベースを検討したり、買ったりしました。結果はほとんどスカでした。dBASEのWin版はどっからもなかなかでないし、新製品を買ってもカード型データベースに毛がはえた程度だったり、まあ、ろくなものはありませんでした。そのなかでAccess Ver1.1はやっとでた存在だったので、他に選択肢はありませんでした。しかもオフィスを買えばほとんどおまけで手に入るようなものでしたから！たしかFoxProは別会社の製品で、マイクロソフトが買収したのだと記憶してます。（あまり確証はもてない。）自分の弱いところを買収で補う、マイクロソフトのもっとも得意とする戦略だと思います。 FoxProはもともと日本では販売されていない製品でしたし、日本ではAccessに対抗できるデーターベースがないという状況だったので、そのままになっているだけだと思います。 >アメリカではAccessはあまり使われておらず、マイクロソフトもそのうちAccessを >切り捨ててしまうかもしれないというお話も聞きました。そうでしょうね。だからこそFoxProを買収したのでしょうから？でも、とんでもない話です。文句言いながらも使っている開発者が日本には山ほどいるというのに！ >もっと末端のエンドユーザーにとっては、エクセルか >桐かというお話があってもいいのではないかと思うのです。たしかに、Accessを生のままエンドユーザに使わせるというのは論外です。桐の操作性（といってもDos桐しか知りませんが！）であれば、多少教育すれば使えますし、そのぶん開発に手が抜けます。(^^;) >エクセルの貧弱なデータベース機能に不満を持ったとき、その人はやはりAccessを >使うのでしょうか？ Excelのユーザーでデータベース機能を使う人は１０人にひとりもいないと思います。たしかに、Accessを選ぶ人はいるでしょうが、使える人は非常に少ないと思います。 >とっつきにくいAccessを使うより、桐の方がずっと簡単に高度なデータベース処理が >できるということを、エクセルユーザーに知って欲しいと思います。少なくとも日本ではAccessをエンドユーザにつかわせるなどもっての他だと思います。だからといって、開発用としては問題が多い。結局苦労して作っても、所詮はスタンドアローンで使うしかない。エンドユーザ用にも開発者用にも中途半端。使用環境がスタンドアローンのシステム開発用には確かにいいかも？これから、そんなニーズがあるわけがない！書いているうちに、Access使っているのがいやになった。やっぱり桐に変えよう！！一括処理にはまだ多少問題があるみたいだけど、工夫次第でなんとかなりそうだ！
511	Re:	悲しげ	1998/11/4-00:32
記事番号507へのコメントどもっ、ＭＩＴさん、ikjunさん、幅田さん、達人の方々の興味深い応答を面白く読ませていただきました。私は桐しか使ったことがないので、とても参考になりました。とともに、何て云うか、桐を使っていることに安心しました。(^^) さて、ひとつとても気になったことがあります。ちょっと古いですが、ＭＩＴさんがNo.500で述べられたこと。＞Ｗｉｎｄｏｗｓのプログラムがだいたいそうであるようにネスト構造は処理速度が＞低下しています。繰り返しコマンドなどは記述によっては動きが見て取れるほど＞遅くなります。これが、直接次のことを指しているのかどうかは判りませんが、似たようなことで痛感したことがあります。桐ver7で次のような記述をした時　　ジャンプ　行番号=1 　　繰り返し(.not #EOF) 　　　・・・・・・・・・・・　　　ジャンプ　行番号=+1 　　繰り返し終了それこそ、処理過程の逐一が画面に表示されます。カーソルが先ず先頭行に移り、次いで１行づつゆっくりと（！）下がっていくのが見えます。ｖ５の場合では、この過程は殆ど瞬時だったのですが、ｖ７では非常に遅いのです。この点について私は、処理過程を逐一画面に表示するために遅いのだ（１行づつウィンドウに描画することに時間がかかっている）と思っていました。つまり、ｖ７では処理の経過を（表示しない仕様も有り得たのだが）「あえて」表示する仕様を選択したのではないか、ｖ５のように処理過程を画面に表示しないことによって速くなるのではないか、（つまり次の版ではそのように仕様を変更してもらう可能性もある）と考えた訳であります。ところが先のＭＩＴさんのご発言を見るに、これはそもそもＷｉｎｄｏｗｓの仕組みに由来しているところの、どもならんことなのかもしれない、と思ったり……。で、結局は想像をたくましくするしかないのかもしれませんが、皆さん、どちらだと思います？ついでに、伝票フォームでの「置換」の挙動が異常に遅いのも不思議です。これが、単にＫ３の努力不足に由来するものなのか、あるいはＷｉｎに由来する不可抗力的なものなのか？　この点の皆さんのお考えも、お聞かせいただけたら幸いです。 PS: ついでにikjunさん、「メーリングリスト」って時々聞くんですが、これってどのようなものですか？あっ、ずっこけてますね。(^^;) いえ、お暇があるときで結構ですんで、簡単に教えて下さい。お暇がなければ結構ですけど。
513	Re:	ikjun	1998/11/4-02:27
記事番号511へのコメント >どもっ、ＭＩＴさん、ikjunさん、幅田さん、 >達人の方々の興味深い応答を面白く読ませていただきました。私は桐しか使ったこと >がないので、とても参考になりました。とともに、何て云うか、桐を使っていることに安心 >しました。(^^) どうもはじめまして、ありがとうございます。大変ありがたいのですが、私を達人の仲間に入れていただくのは、ちょっと間違いです。 Accessの会議室ではひよっこのひよっこ、にわとりの精子ぐらいの存在です。(^^;) なんせ、ふだんはメインフレーム（知ってます？なんでもコンピュータのリース料金が月々１億を越すという話ですから、次元が違いすぎます。）を使っている人まで参加するのですから？劣等感にさいなまれる日々です。でも桐ならば今からでもそれなりに使えそうな気がします。 >ところが先のＭＩＴさんのご発言を見るに、これはそもそもＷｉｎｄｏｗｓの仕組みに由来し >ているところの、どもならんことなのかもしれない、と思ったり……。 >で、結局は想像をたくましくするしかないのかもしれませんが、皆さん、どちらだと思い >ます？えーと、Win版の桐を使用したことがないので、なんともいえないのですが、ダイナミックコンパイラという手法があります。（えーと、見かけはインタプリタでも実行の際にはコンパイルしてから実行）これをWin版の桐が採用すれば、劇的に改善される可能性があるのではないかと勝手に推測します。あと表示を抑制するコマンドがあれば、かなり改善するはずです。この辺はまだ一括処理が未整備だということではないでしょうか？ >PS: >ついでにikjunさん、 >「メーリングリスト」って時々聞くんですが、これってどのようなものですか？ >あっ、ずっこけてますね。(^^;) >いえ、お暇があるときで結構ですんで、簡単に教えて下さい。お暇がなければ結構で >すけど。いや、今はお暇なんですけど、アルコールがかなりはいっているので正しいことを書いているかどうかわかりませんが、とりあえず！メーリングリストというのは、ここのBBSにかなり似てます。違うのはWebPageではなく、メールを使うことです。参加メンバーが、あるメールアドレスにメールをだします。それを自動的に参加メンバー全員に転送します。このことによって参加メンバー全員が情報を共有できます。それを繰り返すことにより、会議室のようなことができます。メリットはメールできますので、わざわざ、WebPageを見に行く必要が無いこと、必要ならば添付ファイルの形でプログラムを送ったり、画像を送ったりできること、電話代が安く済むことでしょうか？わたしは、いま、Excel,Access.その他で一日１００件以上のメールを受け取ってます。正直善し悪しなんですけど、桐のメーリングリストがあれば参加してもいいかなと思ってます。なければ、知り合いに頼んで作ってもらえないかなどとおもっているのですが？（やったことはないのですが、それほど難しいことではないはずです。）
520	Re:	MIT	1998/11/4-18:22
記事番号511へのコメント悲しげさんは No.511「Re:桐からAccess,Accessから桐?」で書きました。 >どもっ、ＭＩＴさん、ikjunさん、幅田さん、 >達人の方々の興味深い応答を面白く読ませていただきました。私は桐しか使ったこと >がないので、とても参考になりました。とともに、何て云うか、桐を使っていることに安心 >しました。(^^) コメントいただいた皆さんこんにちは私も達人ではありません。元々エンドユーザーです。桐は比較的長く使っているのでＤＯＳ桐については多少詳しい程度です。データベースシステムというジャンルは習得に時間がかかるものだと思いますし、経験は年月がないと得られませんので新しいデータベースシステムで達人は存在しないと思います。以前に書いた「Ｗｉｎｄｏｗｓのプログラムがだいたいそうであるように」は私の経験則に基づくものです。実際にＷｉｎｄｏｗｓのオーバーヘッドがどの程度作用しているのかは把握していません。悲しげさんのおっしゃる繰り返し記述のように表を移動する処理でフォームを表示していると、レコードを次々表示して明らかに遅いですね。また、置換、＃表引きなどもＤＯＳ桐に比べて遅いと思います。一括マニュアルの冒頭に結合表の記述がある意味が指し示すのかも知れませんが、それらの処理のうち結合表を用いるとできるものは、その方が高速化するようです。
531	Re:	はまだ	1998/11/6-23:20
記事番号506へのコメント >いつかどこかで書いたことですが、Accessか桐かというのは、ある程度のシステムを >構築できる人のお話であって、もっと末端のエンドユーザーにとっては、エクセルか >桐かというお話があってもいいのではないかと思うのです。 >エクセルの貧弱なデータベース機能に不満を持ったとき、その人はやはりAccessを >使うのでしょうか？ >とっつきにくいAccessを使うより、桐の方がずっと簡単に高度なデータベース処理が >できるということを、エクセルユーザーに知って欲しいと思います。 > 幅田さんこんにちは、お忙しい中、ホームページの運営管理ご苦労様です。エクセルユーザというより表計算ユーザに仕事の効率化のためにも是非ともデータベースを使ってほしいと思っています。表計算アプリのデータベース機能がどれほど貧弱であろうと、手書き仕事、ワープロアプリしかしたことがない人は、データベース機能を表計算アプリにもとめると思います。それほどデータベース機能は仕事に不可欠であるということです。そんな人達に是非ともデータベースアプリを使ってもらいたいものです。その時の選択肢は表を直接操作できる桐しかないでしょう。ところで私の桐Ｖ５一活処理は２０００年に対応していません。当初の思惑ではAccsseか桐Ｖ７の日付型で楽に対応するつもりでしたが、予算が（ハードが１台以外ＤＯＳ／Ｖ）私の脳みそが２０００年までにおいつかないでしょう。まあ２０００年３ケ月前に現行のシステムを１９５１から２０５０まで対応にさせるのがせきのやまでしょう。がっくり・・（ひそかにあきらめていませんが）