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

587	Accessって初心者向け？（桐と比べて）	ikjun	1998/11/23-22:48
桐側からみたAccessの問題点をまとめてみました。「Accessユーザーから桐なんか使っているの？」と言われたら、このように言い返しましょう(^^;) まずは「Accessって初心者向け？」ですが、希望があれば「Accessは上級者向け？」、「アクセスは中級者向け？」でも書いてみようかな？ 「Accessって初心者向け？」 　Accessを理解するためには最低でも、オブジェクト指向、イベントドリブン、メソッド、プロパティ、ＳＱＬ、ＶＢＡなどを理解する必要がある。 　オブジェクト指向、イベントドリブン等はわかってしまえばどうってことないが、なかなか説明の難しい概念である。 ＳＱＬはそれだけで厚い説明書がいるし、ＶＢＡも何冊本があっても、とても記述しきれないほど奥が深い。 （必ずしも、難しいというわけでもないが、覚えることが多い。） 　いろいろと、初心者向けにするようにする努力の跡が見られるが、元々の考え方が初心者向けとはいえないので、かえって複雑になっている。 　桐なら、専門知識は最低で済むし、一括処理は日本語表記でとってもわかりやすい。命令も少ない。 　Accessは、結構バグもある。（データが消えてしまう恐ろしいバクまである。 滅多に起きるものではないが？）特に日本語化に起因すると思われるバグらしきものがあるので、念のためにオブジェクト名などもアルファベットにするほうが問題がないようである。 ただ、こんなことではとても初心者向けとはいえない。 　桐なら、元々が日本語での開発であるから、そういう気遣いは無用である。 その他のバグはもちろんあるだろうけど、管理工学のことであるから、神経質なくらいにとっていくであろう。 　データベースの使用目的のほとんどは、事務処理だと思われる。そして、事務処理のほとんどは入力と集計と出力で済んでしまうので、細かい設定をしなくても標準で済んでしまう桐のほうが、実務にあっている。 　凝った入力をするならAccessだけど、ほとんどがユーザーのつまらない思いつきだったり、単なる慣れの問題だったり、その必要性を突き詰めるとあまりないことが多い。 　特にプログラム以外の仕事を持っている人であれば、桐の手軽さはその欠点を補ってあまりある。 最初のデータベースにAccessを選ぶのは不幸の始まりだと思います。
598	Re:	デザイア	1998/11/24-17:35
記事番号587へのコメント > Accessを理解するためには最低でも、オブジェクト指向、イベントドリブ >ン、メソッド、プロパティ、ＳＱＬ、ＶＢＡなどを理解する必要がある。オ >ブジェクト指向、イベントドリブン等はわかってしまえばどうってことない >が、なかなか説明の難しい概念である。ＳＱＬはそれだけで厚い説明書がい >るし、ＶＢＡも何冊本があっても、とても記述しきれないほど奥が深い。 >（必ずしも、難しいというわけでもないが、覚えることが多い。） お説ごもっともです。桐だと、コマンドと関数ぐらいでよかったのに・・・ Accessにはメソッド、プロパティ、ＳＱＬ、ＤＡＯ、「変数」まである！ ４０才すぎて新たに挑戦するのはつらいです。 >　桐なら、元々が日本語での開発であるから、そういう気遣いは無用である。 >その他のバグはもちろんあるだろうけど、管理工学のことであるから、神経 >質なくらいにとっていくであろう。 ちょっと疑問、一抹の不安？ >　データベースの使用目的のほとんどは、事務処理だと思われる。そして、 >事務処理のほとんどは入力と集計と出力で済んでしまうので、細かい設定を >しなくても標準で済んでしまう桐のほうが、実務にあっている。 ＤＯＳのまま、最近のネットワークに対応してデータ授受だけできるようにしてくれたらそれでよかったのに。 それから、同時に開ける表数等の制限をちょっと緩めてくれたら・・・ 後は開発要員の制限です。地方都市では「めったにいない」。 時間があれば自分で全部やるんだけど・・・　でも、それは＝メンテ要員自分だけ。 >　特にプログラム以外の仕事を持っている人であれば、桐の手軽さはその欠 >点を補ってあまりある。最初のデータベースにAccessを選ぶのは不幸の始ま >りだと思います。 Ver.5でがんばります。 以上
616	Re:	ikjun	1998/11/25-10:10
記事番号598へのコメント >　ＤＯＳのまま、最近のネットワークに対応してデータ授受だけできるよう >にしてくれたらそれでよかったのに。それから、同時に開ける表数等の制限 >をちょっと緩めてくれたら・・・ WinNTのネットワークに対応するのは、メモリの関係でまず無理だろうし、同時に開ける表数等の制限はDosのメモリの制限のせいだろうから・・・・ >　後は開発要員の制限です。地方都市では「めったにいない」。時間があれ >ば自分で全部やるんだけど・・・　でも、それは＝メンテ要員自分だけ。 逆に後輩を指導教育して戦力にするなら、これほどいいものはないのでは？ >　Ver.5でがんばります。 気持ちはわかりますが、すでにDosの動かないDos/V機（？）というのも出てきているそうです。 いずれは移行せざるえないのでは？ というわけで（どんなわけだろう？）こんなことも書いてみました。 「Accessは上級者向け？」 　Accessは上級者向けとして、苦労して覚えるかいがあるかというと、そうもない。 やはり世界標準のマイクロソフトが一番などと考えがちであるが、実はAccessは海外ではあまり使われてない。Accessを覚えれば世界で通用するプログラマになれると思ったら大間違いである。Xbaseのほうがいい・・・ 　桐より入力などの細かい制御が利くというのは確かではあるが、とことんやろうと思うとAPIやBasicやCを併用しなければならなくなる。 逆に桐で簡単に出来ることも結構面倒な記述をしなければならない部分も多い。 　当然本格的なシステムとして開発する場合には、排他制御は必須であろう。 ところが、Accessでは、レコード単位の排他制御ができない。 しかも、マルチユースで使おうとすると、データベースが壊れやすくなるという、とんでもない欠点がある。 参考->http://www.bsaku.com/~nabo/access/index.html 　じゃあどうすればAccessでレコード単位の排他制御が可能かというと現状で一般的なのはOracleを使うことであるが、これがめっぽう高い。 メインフレームなどをやっていた人たちから見るとえらく安いらしいが、Accessは安く済むと思っている人にとっては目の玉が飛び出るような価格である。 　マイクロソフトにはOracleに対抗して、SQL Serverがあるが、実はSQL Serverは現バージョンではやはりレコード単位の排他制御ができない。 しかもAccessをインターフェースにしてSQL Serverと接続するとレスポンスが悪い。 　また、本格的な開発用にはAccessのすべてのオブジェクトが１つのデータベースに入るという仕様はその他の開発ツールを使いづらくすることになり、大きな開発になればなるほど、都合が悪くなる。 多人数により分担した開発などはかなり難しい。 なにも考えないでやると作るかたっぱしから壊すことになりかねない。
632	Re:	デザイア	1998/11/26-18:04
記事番号616へのコメント 　いろいろご教授いただきありがとうございました。ただ、時代の流れ半分、時すでに遅し半分でしょうか？ 桐Ver.5で組んであるシステムをAccessに置き換えていこうとしております。 　当方の環境は、NetWare3.12Jに、Windows98、95、3.2、Dos5.0、3.3と豊富なＯＳ、メーカーなんでもありという、多様性に富んだものです。 ついでに、Windows95マシンにしても、当初の触れ込みだったメモリ16MB以上＆ＨＤ800MB以上のスペックのもの（以上を程度と読み替えてください）がそこそこあり（当時まちがいなく流通していた！）、これも悩みのタネです。 3.2からのアップグレードもありますね。クライアント数は60程度、オープンセサミのライセンスが16くらいです。 桐一括処理がざっと60本かな。だから、Ver.7へのバージョンアップはちょっと度胸がいります。 　で、おっしゃるとおり、組み合わせて結局どうかですが、あちこちいろいろと問題があるようで、ご機嫌が悪くなりますと立て続けにサーバーが落ちます。 ひどいときには、週７回落ちました。LANケーブルというのもありましたが、発生源を推定してみると桐を扱っていたクライアントです。 原因か結果かかはよくわからないのですが、ちょっと大きめの表にI/Oかけたとか、プアスペックマシンがハングッてる（Dos機は落ちませんね）とか、サーバーメモリが足らない（現在32MB、すっかり最近のクライアントから見劣りしてしまってあわれ）とか、打てる手を打ちながら、ご機嫌伺いあるのみ。 　で、運用体制は開発メンテこみで不肖私一人。プリンタがつまったとかいうCE業務も込みです。 そして、それを数ヶ月前まで工程課長兼務（！）でやっておりました（今は開発シフトではずしてもらいましたが）。 　お話伺ってると、これがさらに泥沼化していくのでしょうか。でも、これ以上悲惨な環境ってないような気も・・・ 　元のテーマから外れついでに、不思議な現象を報告しておきます。 　桐Ver.5には、ユーティリティの表検査で検知できない表破損が発生することがあるようです。 しかし、壊れており一括は落ちます。現象としては、表示してみると項目中に文字化けのような表示が現れます。 レコード単位に壊れるようで、当該レコードを切りとばせば（それをどう復活させるかは別にして）直ります。 ただし、破損レコードに切り残しがあると破損が増殖するようで全項目、項目集計かけるのが一番カタいようです。 　サポートにデータをフロッピィで添付して問い合わせたら、「修復」して返してくれただけでした（数日前の在庫データを修復してもらっても！？）。ということで、原因等は不明です。 　あと、我々の環境ではクライアント数が限られるので、表の開け閉めをできるだけこまめに行い、排他で引っかかったクライアントはループで待たせておくという、原始的手段がけっこう使えます。 ただ、動いているシステムに、表・項目を追加しながら、一括も修正・追加していくのは、なかなかの仕事であり、その大変さがめったに理解されることがないというのがつらいところです。 以上
633	Re:	デザイア	1998/11/26-18:15
記事番号632へのコメント いい忘れました。 　当然のことながら、Access用にNTサーバーを追加します。 NetWareだけで充分手を焼いているので、いやだったんですが。 以上
638	Re:	ikjun	1998/11/26-21:31
記事番号632へのコメント >いろいろご教授いただきありがとうございました。 　いいえ、ただ単に思いついたことを書いただけです！あーすっきりした。 >桐Ver.5で組んであるシステムをAccessに置き換えていこうとしております。 　あちゃあー、それはそれはご苦労様です。Access会議室、メーリングリストなどはご存じでしょうか？ すすめはしませんが、事情もあるでしょうから、どうしてもやめろとはいえません。 Accessの情報はインターネット上にごろごろしてます。これが最大のAccessの利点でしょう！ >　当方の環境は、NetWare3.12Jに、Windows98、95、3.2、Dos5.0、3.3と >豊富なＯＳ、メーカーなんでもありという、多様性に富んだものです。 　キャアー、のけぞっちゃう！多様性に富んだトラブルが出そう。せめて、DosのVersionくらい統一できないのかなあ？Dos6.2に統一して、Qemmなどを使用して、コンベンショナル・メモリを確保。WindowsはWinNTのワークステーションに変える。 これだけでかなり安定化するような気がする。そういえばNetWare3.12jは２０００年問題に対応してないとか？聞いたような気がする。 >ついで >に、Windows95マシンにしても、当初の触れ込みだったメモリ16MB以上＆ せめて３２MBにしたほうがいいとおもうけど？できれば64MBにしてWinNTワー クステーションというのがベター！ >クライアント数は60程度 　クライアント数60？これをAccessで動かすの？もしJetエンジンをそのまま使うとすると自殺行為だと・・・・・ナンマイダ・・・・・・・ >プアスペッ >クマシンがハングッてる（Dos機は落ちませんね）とか、 クッワー・・・・ところで、Windows95って一ヶ月間電源をいれたまんまにしておくと自然にハングアップするって知ってました？ >　で、運用体制は開発メンテこみで不肖私一人。プリンタがつまったとかいう >CE業務も込みです。 ほとんど、トラブル対策だけで１日が終わるのではないですか？ >　お話伺ってると、これがさらに泥沼化していくのでしょうか。でも、これ以 >上悲惨な環境ってないような気も・・・ そうでもないかも？ >　元のテーマから外れついでに、不思議な現象を報告しておきます。 えーと、Accessのデータも良く壊れますよ。しかもプログラムを道連れにする！ >　あと、我々の環境ではクライアント数が限られるので、表の開け閉めをでき >るだけこまめに行い、排他で引っかかったクライアントはループで待たせてお >くという、原始的手段がけっこう使えます。 なるほど、その手がありますね。 >ただ、動いているシステムに、表 >・項目を追加しながら、一括も修正・追加していくのは、なかなかの仕事であ >り、その大変さがめったに理解されることがないというのがつらいところです。 お気持ちよくわかるような気がします。
640	Re:	はまだ	1998/11/26-22:10
記事番号632へのコメント デザイアさん、はじめまして。 >Ver.7へのバージョンアップはちょっと度胸がいります。 　そうですね、いまどき追加ライセンス３６，０００はないでしょう。Ｋ３さん・・ >クライアント数は60程度、オープンセサミのライセンスが16くらいです。 　これははたして、桐、ＤＢプロ、ファイルメーカ、アクセスを開発ツールとして選択する環境なのでしょうか。 これはデータベースエンジンにＣ／Ｓデータベースを導入し、それそうおうのフロントエンド開発ツールをプロに委託しなければならないのではないでしょうか。 >運用体制は開発メンテこみで不肖私一人。プリンタがつまったとかいう >CE業務も込みです。そして、それを数ヶ月前まで工程課長兼務（！）で >やっておりました（今は開発シフトではずしてもらいましたが）。 　ご苦労様です。システムの管理者のご苦労はだれもわかってくれないでしょう。 ただ、桐のよいところはエンドユーザに最低限の会話処理を覚えてもらえば、取合えずメニューから表（帳票）形式編集コマンドで急場をしのげるという良さがあります。 また一括処理もしかりです。簡単な会話処理の次の段階として履歴の操作、一括処理への取込みをおぼえてもらい。 入社１年くらいで部分部分の一括処理のかきかえを自分たちでできるまでになりました。 もちろん本業は各々もっていますが、自分の実務に即した部分が省力化、効率化されるとなれば問題なくおぼえてくれます。 >　あと、我々の環境ではクライアント数が限られるので、表の開け閉めをでき >るだけこまめに行い、排他で引っかかったクライアントはループで待たせてお >くという、原始的手段がけっこう使えます。 　私も相当つかえるとおもいます。ただ、私の基本的な考え方は、更新ＴＢＬはクライアント毎（サーバの各自のディレクトリ）に持ち、ユニークキーを管理しているＴＢＬのみループでまたせる。 小さなマスタはできるだけ各クライアントが持ち、自分のテーブルは即時更新し相手方の作業ファイルに差分データを書き出す。 相手側はメインメニューに戻るときに差分データを自動更新する。 というパターンをとっています。大きなマスタもできるだけハードディスクの容量の範囲でできるだけ複数持つようにする。 各クライアントの更新（競合）パターンを考え、あまり競合しないグルーピングをして、ＴＢＬを操作するようにする。 という方法をとっています。無理に擬似レコードロックをするよりはるかにいいと思いますが。どうでしょうか。 ただ、これは同じ部署でクライアントが５〜６台が限度でしょう。所詮ファイル単位ロックです。 何のアドバイスもできませんでしたが、これからもがんばってください。