まずは、テキストファイルを作ってしまう。エクスプローラ等でResourcesフォルダを開いたら、フォルダの中身を表示しているウインドウを右クリックする。するとメニューが表示されるので、「新規作成」から「テキストドキュメント」を選択する。すると、「新規テキストドキュメント.txt」というテキストファイルが作成される。通常は「メモ帳」が関連づけられていて、ダブルクリックすれば開くはずだ。
◇新しくテキストファイルを作成する
作成された「新規テキストドキュメント.txt」をダブルクリックして開き、単に「8」という半角文字の数字をキータイプする。そして保存しておく。この8とういのは、NSShiftJISStringEncodingということを意味するそうで、文字のエンコードでシフトJISを使うということを設定することになる。
◇テキストファイルの中身は「8」だけでよい
保存をして、「メモ帳」を終了する。そして、ファイル名を「CStringEncoding」にする。ここで、.txtの拡張子は削除されることになり警告が表示されるがかまわず、このファイル名に変更をする。
◇ファイル名を「CStringEncoding」に変えておく
この準備は、インストール後に1回行うだけでよい。
実はこの後、実にさまざまなパターンで、Accessのデータベースを利用できるような、WebObjects Applicationを作った。そこでとにかくこうすれば稼動するというパターンは何とか見つかったという状態だ。最初悩まされたのは、Accessのデータベースのテーブル名やフィールド名が、2バイトコードの場合、Project Builderでの作業中に文字化けするということだ。しかし、理由が定かでないのだが、2バイト文字でも問題はないようだ。インストールの状態が何かでうまくいかなかったのかもしれない。フィールド名などは1バイトコードで記述するのが基本と言えるのかもしれない。だが、Direct to Webではフィールド名そのものが初期状態では一覧の見出しになるので、日本語で扱いたいとも考えるところだ。
次は、Accessのデータベースでの考え方と、EOModelerの考え方が微妙に違う点があることだ。Direct to WebでEOModelerによるデータベースのモデルを生成するのだが、ウィザードの途中で主キーをフィールド一覧から選択して指定をする必要がどうもあるようだ。主キーを指定しないで進めた場合、実際にアプリケーションはきちんとは動かない。Accessのテーブルは、フィールドに対する主キーはあらかじめ設定されているので、そこのところは自動的に取得してやってくれないのかと思ったのだが、どうしてもそうはいかなかった。ウィザードの途中で主キーを設定することで、とりあえずは検索などはうまく動くようになったので、これは必須なのだろう。だが、Webブラウザからのレコード追加を解析してみた結果、Accessのオートナンバー型フィールドと、EOFのモデルとのからみがうまく行っていないような気がする。これについては回を改めて記載しよう。参照だけでいいのなら、オートナンバー型フィールドでもいいのだが、Webブラウザからレコードを追加を行うには、データベースの修正も含めて、あちらこちらを変更しなければならない。
それから、これもけっこう悩んだのだが、テキスト型のフィールドの扱いだ。Accessのテキスト型フィールドでは255バイトの長さまで設定できる。ただし、255バイトに設定していると、モデルを作るときに正しく認識がされないようで、EOModelerで設定内容を見ると、正しい設定になっているとは思えない。ただ、たとえば50バイトのテキストフィールドは、EOModelerでの長さは100になっている。UNICODEということなのだと思うがちょっと釈然とはしない。いずれにしても、長さが254バイトなら問題はないようなので、255バイトのテキスト型フィールドの長さを詰めておこう。テキスト型フィールドにぎりぎり文字を入れることも滅多にないと思われるので、多くの場合はこれで問題はないはずだ。
いずれにしても、ODBCだからなのか、やはりAccessをデータベースに使うのは立て板に水というようにはいかないのである。Accessを使うことでわざわざ悩み、時間を食うとなれば、本末転倒になる場合もあるだろう。常にチェックをしながら作業をすすめることが肝心だと思う。