マイクロソフト系簡易データベースを解説しているヘルプファイル名

質問

Microsoft Basic では，

OPEN File18$ FOR ISAM Custbl "Nani" AS #11: '要 TYPE宣言 Custbl
CREATEINDEX #11, "CuIDIdx", 0, "Siran": '重複可 インデックス名"CuIDIdex" 新規作成
SETINDEX #11, "CuIDIdx"

より簡易データベースを使用できました。これらは、 cobol の sort file の雰囲気で使用してきました。
Visual Studio 6.0 の Visual Basic 文法ヘルプ(VBENLR98.CGM)内 OPEN ステートメントには，記載がありません。
マイクロソフト系簡易データベースを Visual Basic で利用するための文法を解説しているヘルプファイルはどれなのでしょうか。
それとも Professional Edition のため入っていないのでしょうか。

回答No.7

ARC

>システムが合わないです。

ん～、環境によって違いはありますからね。
お使いのOSのバージョン、VBのバージョン、DAOやADOといったミドルウェアの種類とバージョン、エラーが出るのであれば、その時のエラーメッセージ等があれば、より詳しい回答が付くかと思いますよ。

とりあえずカンでの回答なのですが、参照設定を見直されては如何でしょうか。
お書きになったURL(http://acvb.s19.xrea.com/doc/013.html)と同じような参照設定になっていますか？

＞また.覚える価値があるかどうかは疑問です。というのは.
：
＞と変化しています（いずれも私の環境では動作しません。）。

に関しては、バージョンによる構文の違いではなく、複数の書き方がサポートされているってことです。
この辺の文法は、昔からさほど変わっていないので、VB6.0であればどちらの書き方で書いても動作すると思います。
(逆に言えば、動作しないのであれば、構文以外の面が原因であると思われます。)

(以下、蛇足です)
確かに、コンピュータ関連は変化の早い業界ですよね。
次から次へ新技術が登場して、古くなれば容赦なく切捨てられる…
覚悟の上とはいっても、因果な商売だと思いますね、自分でも。

ミドルウェアの変遷にしても、MS社だけで15年間で3世代ですか。それ以外にもJAVAにはJAVAのミドルウェアがあったりと、数を挙げていけばきりが無いですねぇ。
結局、どんなやり方を採るせよそれぞれ一長一短があって、その時々でどれにするのかを決めていかなくてはならないんですよね。
もし、将来にわたって技術の変化が無いことが保障されているんであれば、心置きなく日々の勉強をサボることが出来るんですが（笑）。

>また.マイクロソフト社におけるデータベース関係の文法の変化が著しいので.自分にあったライブラリを用意して.以後.このライブラリだけを使用することを考えたほうが良いかと思います。

確かに、用途を限定するのであれば、そういう考え方も有るかと思います。
データの規模も行うデータ操作も(将来にわたって)一定の範囲内に限定されているのでしたら、恐らく仰るやり方の方が有利なのでしょう。

反面、複雑なデータ操作を行ったり、大量のデータを高速に処理する必要に迫られたり、といった局面がもし有るのだとすれば、やはり独自ライブラリでは限界が出てしまうのではと思います。
既存のライブラリを使えば数行で済む内容を、独自ライブラリのために数百行も費やして、テストや仕様書作成の手間もかけなくてはならない、といったコスト面での問題も出てくるでしょうし。

お礼

どうやら原因が特定できました。
http://www3.kcn.ne.jp/~wataru/vb/ado.htm
等で
cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & lstrPath & ";"
のように末尾に半角の「；」を入れてOpenしていますが、これが抜けていたために

lstrPath = App.Path & "\test.mdb"
cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & lstrPath & ";"
lstrSQL = "select * from student"
lobjRS.Open lstrSQL, cnn, adOpenForwardOnly, adLockPessimistic
のように「, cnn, adOpenForwardOnly, adLockPessimistic」を指定するような構文が全部エラー(オブシェクトを指定しろ)になりました。

またこのような宣言された語を使用しないでOpenする
myRS.Open "Select * from 名簿テーブル"
では.レコードを追記ができない状態でOpenされるために.わけのわからない英語のエラーメッセージ(3251)が表示され
myRS.AddNew
以下の構文がつかえなくなります。こちらは.末尾の「;」がなくてもOpen可能です。

文法エラーが発生しない障害なのか.省略形を認めている使用なのかヘルプメッセージからは読み取れませんでした。
本来ならば「何というオブシェクトがどこで抜けているから.指定しろ」とか.「○文で指定した構文によってこの命令は使用できない。使用するのであれば○文に×という指定を追記しろ」くらいのエラーメッセージを表示すべき（私の使っていたデカコンはメモリーが1MB、HDDが128MBしかないにもかかわらずこのあたりのエラーチェックは厳格であった）でしょうか、マイクロソフトのエラーメッセージ・ヘルプメッセージでは省略されています。
ヘルプファイルを眺めた雰囲気からすると任意のところを変更しても他のところを変更しないですむような文章の書き方であり、マニアルとしては欠陥商品でしょう。

一応.Open, Close, Read, Writeの４命令が使えるようになったので、一応区切りとし、他の問題は別の質問として掲載したいかと思います。いろいろありがとうございました。

補足

参照設定はあわせてありました。ただ.余分な設定の影響があるかもしれません。
使用していた機器のおそらくメインボードが半断線になり、振動で暴走するようになりました。原因の特定および復旧作業に手間取り応答が遅れたことをお詫びいたします。

ms-basicでISAMの制限を逃れるソフトを作ってありますので、ちょっと移植する程度です。速度は期待していません。ms-basic+ペンテ133MhzのPC-9821（1996年頃）の半分程度の速度しか、VB 6.0発売当時(1999年頃)のWindowsでは出ませんから。
また、大きな問題（ボリウム分割が必要程度の大きさ）には、マイクロソフトの製品では未対応です。この点は自作ソフトで目一杯苦しんだ内容です。従って対応済みです。
小さくない問題（同一ボリウム内の1/3程度の大きさ迄）では、複数キーの問題があります。私のソフトではシングルキーしか対応していません。当座の問題としては、キー以外の内容を元にして削除を行う時に全体を読みなおす必要があることです（ISAMではファイルハンドルが1キーあたり3つも使われる。システムに3+3必要で、ユーザーファイルを１０個ぐらい同時openしているので、１キーしか作らなかった）。
またセクター長が固定なので最大長にあわせる必要がありファイルによっては90％以上が空白の場合があります。
複数フィールドに分割保存する方法（ｎ88等の256固定フィールドの頃に良く使った方法。何人も絶句させてしまったので今はあまりやりたくないです）もありますが、データを固定して保存する方が楽で複数キーに対応する時にでも考えましょう。
小さな資源(1000個以下程度)では.システムが巨大過ぎるという問題があります。元々ボリウム分割を前提に作った内容なので、入力ボリウムが複数・出力ボリウムが複数・作業ボリウムが複数なんて余計な作業内容がありますから。

先日1つ移植して10000個1MB程度の少ないデータ量ですが.PC-9821(ペンテ133Mhz)で20分、Win98SE(ペンテ２400Mhz)で１時間程度と比較的高速に処理しているようです。これは、MS-Basicのメモリー制限で20-40KB程度以上のユーザーメモリーを使用するとシステムがハングするという特徴があります。そのために、少量づつ処理しているのでマルチタスク処理の場合に（他のタスク(Visual Basic本体等)の切り替えに使われてしまい）速度が遅くなりやすいためでしょう。処理単位を可変にして適当な場所を見つけるか、ご指摘のようにADOに変更するか、どちらにするか、今迷っています。