すでに存在するデータベースに接続するので、最初の画面で&quot;既存のデータベースに接続&quot;を選択する。相手がOracleなので、順当なADOで選択することにする。ドライバは、Microsoft提供のものとOracle提供のものとがあるが、Oracle提供のものを選ぶことにする。<br />
データソースのURLを聞いてくるので、&quot;ブラウズ&quot;ボタンを押して、ウィザードに従い接続文字列を作成する。(ちゃんと接続テストもする)<br />
完了したら、データベースの定義を保存しておく。拡張子はodbになった。<br />
<br />
テーブルボタンを押して、テーブル一覧を表示する。Accessの様にいちいち各テーブルごとに取り込むテーブルとキー項目を指定する手間がないのはうれしいが、システム関係のテーブルまで表示されるのが不快だ。<br />
ここで問題のテーブルを開く。すると214万件ほどレコードが存在するのだが、最初に表示されたのが47件、したにずりずりスクロールバーを下げると94件で止まってしまった。<br />
<br />
OpenOffice.orgの問題かとも思ったが、ADOドライバの可能性を捨てきれずDelphiで同じドライバを使ってデータ表示プログラムを作成する。Delphiの特徴として設計画面でも実行時と同じデータが参照できるのだが、データを絞っていなかったせいもありBaseとは対照的にデータを読み込むのに結構待たされた。では、「テーブル」ではなく、「クエリ」ではどう表示されるかと、シンプルなSELECT文を作って発行したが状況は変わらなかった。<br />
<br />
データ件数は少ないまでもCSVに出力するテストをと思い、一覧でテーブルを選択 ファイル|名前を付けて保存 を実行。ダイアログを表示したが、出力形式として選択できたファイルの種類は&quot;OpenDocumentデータベース&quot;のみ。<br />
期待していただけにがっかりだ。Baseのこの出来を見ている限り、Sunも何に無駄な投資をしているんだろうと考えてしまった。<br />
<br />
WriteやCalcは使うユーザも多いだろうから、もうちょっとまともなのであろうか？<br />
※ Accessが取り扱えないデータとは、以下に該当するテーブルである。<br />
<ol>
    <li>プライマリインデックス(キー)が無く、フィールドが10以上あるテーブル </li>
    <li>プライマリインデックスが10以上あるテーブル</li>
</ol>
Accessはキーを10個しか取り扱うことができないので、上記のようなデータを表示するとデータがおかしくなる。対策としては、各レコードにユニークなシーケンス番号を与えることだ。