32 ビット用の ODBC データソースアドミニストレーターは以下のディレクトリに配置されています。
C:\Windows\SysWOW64\odbcad32.exe
たとえば、接続先のアプリケーションが 32 bit 版にしか対応していない場合は、odbcad32.exe を使用して ODBC 接続設定を行います。
2010-11-08
Windows 2008 R2 64 ビットで 32 ビット用の ODBC ドライバを動かす
Windows Server 2008 R2 64 ビット環境で 32 ビット版用に開発された ODBC アプリケーション（例：FileMaker Server 11） は、通常の ODBC データソースアドミニストレーターからは参照することも使用することもできません。
32 ビット用の ODBC データソースアドミニストレーターは以下のディレクトリに配置されています。
C:\Windows\SysWOW64\odbcad32.exe
たとえば、接続先のアプリケーションが 32 bit 版にしか対応していない場合は、odbcad32.exe を使用して ODBC 接続設定を行います。
32 ビット用の ODBC データソースアドミニストレーターは以下のディレクトリに配置されています。
C:\Windows\SysWOW64\odbcad32.exe
たとえば、接続先のアプリケーションが 32 bit 版にしか対応していない場合は、odbcad32.exe を使用して ODBC 接続設定を行います。
2010-11-05
『売上猫くん on MySQL』開発日記 - 番外19 - FMで大きなSQLテーブルは扱えるのか？ ― その4
前回は、FM社製のドキュメント（日本語版と英語版）内の一文を引用し、それを小生なり解釈すると「他のフロントエンド開発ツールに比べるとFileMakerのESSはかなり限定されていること、また一見してFileMaker単体のシステムと同じ結果を返すように見えても異なることがある。ユーザはESSの限界と特性を意識して使用すべし」となる旨のことを書いた。これに加えて、同ドキュメントにもう一つ気になる文章がある。
とするとこの文は、「FileMaker純正データベースエンジンが実用的には（“論理的”にではない）取り扱うことができない大きなテーブルをSQLデータベースのそれに置き換えても、やはり実用的には取り扱うことはできない」と言っているのだと思われる。 タイトルにある「 FMで大きなSQLテーブルは扱えるのか？」という命題への直接否定のようだ。
直接否定だとすると、FileMakerの理論上、仕様上の限界はデータベース単位で8TBであるが、実用上の“限界”はどのくらいなのだろう？ 古い記事だが、「（個人的な意見だがテーブルベースで）100万を超える位なら大丈夫だよ」とある。 小社でも数十フィールドあるFileMakerテーブルに100万～200万弱のレコードを収納して数年間、運用している。 200万レコード程度をFileMakerの“限界”と仮定すると、その“限界”を超えて、と主張するには、レコード件数的には400万レコード以上をテスト時の最大数とすれば十分だろうか。ちなみに、『売上猫くん on MySQL』のテスト環境で、いまのところ一番大きなテーブルのレコード数は約180万件である。
ただレコード件数をいくら増やそうとも、ユーザが強いストレスを感じたり、安定性が無いシステムでは“実用的”とは言えない。 “実用的”と言うには、その1とその2で書いたような問題をできる限り顕在化させてはいけない。問題6の激遅ソートは回避策がないので、ユーザによるカスタムソートの実用性は非常に低い。 その他の問題については、回避策を施したり、 運用で調整する（例えば、.fp7ファイルをサーバ上に置かず、ローカルに置く）ことにより、緩和できるものと判断している。 だが結局、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップでき」たかどうかというのは、公正なエンドユーザの判断に拠る、としかいいようがない。
（土屋）
注：
「～限界を超えて～」については、上記の英文をキーにググってみたが（その3の参考URLを参照）、2007年当時は否定的な見方が優勢だった。 2008年以降は関連する記事を見つけることができなかった。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
- ESS は、FileMaker Pro ソリューションを、FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる手段として設計されたものではありません。(ESS is not designed as a means to allow a FileMaker Pro solution to scale beyond the limits of a purely FileMaker Pro based solution.)
とするとこの文は、「FileMaker純正データベースエンジンが実用的には（“論理的”にではない）取り扱うことができない大きなテーブルをSQLデータベースのそれに置き換えても、やはり実用的には取り扱うことはできない」と言っているのだと思われる。 タイトルにある「 FMで大きなSQLテーブルは扱えるのか？」という命題への直接否定のようだ。
直接否定だとすると、FileMakerの理論上、仕様上の限界はデータベース単位で8TBであるが、実用上の“限界”はどのくらいなのだろう？ 古い記事だが、「（個人的な意見だがテーブルベースで）100万を超える位なら大丈夫だよ」とある。 小社でも数十フィールドあるFileMakerテーブルに100万～200万弱のレコードを収納して数年間、運用している。 200万レコード程度をFileMakerの“限界”と仮定すると、その“限界”を超えて、と主張するには、レコード件数的には400万レコード以上をテスト時の最大数とすれば十分だろうか。ちなみに、『売上猫くん on MySQL』のテスト環境で、いまのところ一番大きなテーブルのレコード数は約180万件である。
ただレコード件数をいくら増やそうとも、ユーザが強いストレスを感じたり、安定性が無いシステムでは“実用的”とは言えない。 “実用的”と言うには、その1とその2で書いたような問題をできる限り顕在化させてはいけない。問題6の激遅ソートは回避策がないので、ユーザによるカスタムソートの実用性は非常に低い。 その他の問題については、回避策を施したり、 運用で調整する（例えば、.fp7ファイルをサーバ上に置かず、ローカルに置く）ことにより、緩和できるものと判断している。 だが結局、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップでき」たかどうかというのは、公正なエンドユーザの判断に拠る、としかいいようがない。
（土屋）
注：
「～限界を超えて～」については、上記の英文をキーにググってみたが（その3の参考URLを参照）、2007年当時は否定的な見方が優勢だった。 2008年以降は関連する記事を見つけることができなかった。
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
2010-11-04
『売上猫くん on MySQL』開発日記 - 番外18 - FMで大きなSQLテーブルは扱えるのか？ ― その3
FileMaker のVer9リリース時位にFM社が作成した不思議なドキュメントがある。『Introduction to External SQL Sources』（邦題：外部SQLソース入門）というタイトルが付いており、日本語版と英語版がある。 読んでみると、
と、衝撃の１文がある。ハァ？ SQLデータベースに接続してFileMakerを使用しようとする者ならだれてもFileMakerまたはFileMakerで作成したアプリ（.fp７）がSQLデータベースのフロントエンドとなる、と思っている筈だ。 試しに「filemaker フロントエンド」をキーにググってみると、そう確信して記事を書いている人がたくさんいることがわかる。ところが、FM社の公式見解は、FileMaker（のESS）は、
「フロントエンド」として利用できるようにすることを意図したものではない、のである。 では、FM社がESSとか呼んでる機能なんなの？、ということである。 小生はフロントエンドとは、「ユーザが操作する部分＝ユーザインタフェイス」位に理解していたのだが、念のためググってみると、こんな感じである。
Wikipedia
フロントエンドは、ユーザーと直接やりとりするソフトウェアシステムの部分を指し、バックエンドはフロントエンドへの出力を生成する部分を指す
IT用語辞典バイナリフロントエンドは、一般的に、表示やデータ入力を行うための仕組みを指し、ユーザーインターフェース（UI）と同義と同義で用いられることも多い。
IT用語時点
ユーザからの操作の受付や画面表示などを担当するGUI(グラフィカルユーザインタフェース)プログラムなどがこれに当たる。
元々の小生の理解と大差は無い。であれば“ESS”はバックエンド（データベース）を操作するためのユーザインタフェイス＝フロントエンドと言ってもいい筈だ。ただのユーザインタフェイスなんだから。 にもかかわらず、「FileMaker はフロントエンドじゃないんだ！」と宣言するFM社の意図はなんなのだろう？
ユーザはこの文章についてどう思っているのかと思いググってみたが、それらしき記事は日本のサイトには見当たらなかった。 海外のサイトには、上記のドキュメントに関する記事・投稿がいくつかある。
参考URL
SQL as backend? （2007年7月、V9当時？）
SQL performance: Alpha Five vs. Filemaker 9 benchmarks （2007年9月）
07.12.07FileMaker 9 SQL Link… ish（2007年9月）
beginners odbc question
特に3つめのURLは、Servoyという開発ツールと比較しながら、FileMakerの問題点を以下のように列挙している。
なんとなく解ってきた気がする。 開発者はFileMakerをフロントエンド開発ツールとして使用し始めると、他ツールと比較していろいろと不便な点があることに気がつく。 特に1.データ型、2.ユーザ独自のSQLクエリが実行不能、よって、3.検索、特にソートが非常に遅くなるというのは大問題で、簡単な回避策は無い。 ところが、多くのフロントエンド開発ツールは、何の問題もなくこれらのことを実行できる。 つまり、FM社が「フロントエンドにはなりませんよ」というのは、「他のフロントエンドツールにできることでも、FileMakerではできないことがあります。 その代り、FileMakerっぽくSQLのデータをある程度なら扱えますよ。 でも、FileMaker純正データベースとは違った結果が返ることも大いにありうるので、そこら辺、凄く注意して使ってね！」というのがかなりホントのところではないかと思われる。
（土屋）
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
- ESS 機能セットは、FileMaker Pro をSQL データソースの「フロントエンド」として利用できるようにすることを意図したものではありません。 （The ESS feature set is not intended to allow FileMaker Pro to act as a “front end” to SQL data sources.）
と、衝撃の１文がある。ハァ？ SQLデータベースに接続してFileMakerを使用しようとする者ならだれてもFileMakerまたはFileMakerで作成したアプリ（.fp７）がSQLデータベースのフロントエンドとなる、と思っている筈だ。 試しに「filemaker フロントエンド」をキーにググってみると、そう確信して記事を書いている人がたくさんいることがわかる。ところが、FM社の公式見解は、FileMaker（のESS）は、
「フロントエンド」として利用できるようにすることを意図したものではない、のである。 では、FM社がESSとか呼んでる機能なんなの？、ということである。 小生はフロントエンドとは、「ユーザが操作する部分＝ユーザインタフェイス」位に理解していたのだが、念のためググってみると、こんな感じである。
Wikipedia
フロントエンドは、ユーザーと直接やりとりするソフトウェアシステムの部分を指し、バックエンドはフロントエンドへの出力を生成する部分を指す
IT用語辞典バイナリフロントエンドは、一般的に、表示やデータ入力を行うための仕組みを指し、ユーザーインターフェース（UI）と同義と同義で用いられることも多い。
IT用語時点
ユーザからの操作の受付や画面表示などを担当するGUI(グラフィカルユーザインタフェース)プログラムなどがこれに当たる。
元々の小生の理解と大差は無い。であれば“ESS”はバックエンド（データベース）を操作するためのユーザインタフェイス＝フロントエンドと言ってもいい筈だ。ただのユーザインタフェイスなんだから。 にもかかわらず、「FileMaker はフロントエンドじゃないんだ！」と宣言するFM社の意図はなんなのだろう？
ユーザはこの文章についてどう思っているのかと思いググってみたが、それらしき記事は日本のサイトには見当たらなかった。 海外のサイトには、上記のドキュメントに関する記事・投稿がいくつかある。
参考URL
SQL as backend? （2007年7月、V9当時？）
SQL performance: Alpha Five vs. Filemaker 9 benchmarks （2007年9月）
07.12.07FileMaker 9 SQL Link… ish（2007年9月）
beginners odbc question
特に3つめのURLは、Servoyという開発ツールと比較しながら、FileMakerの問題点を以下のように列挙している。
- SQLデータ変更時、その変更が他のユーザの画面に反映されない
- レコードレベルのロック機能がない
- テーブルやフィールドへの変更が自動的に反映されない
- ユーザが作成するSQLクエリを発行できない（SQLクエリは全てESSにお任せ）
- 未サポートのデータ型がある
- 検索が遅い
- ソートはさらに遅い（バックエンドでソートを行わず、一旦FMにデータをロードした後にそのデータをソートするため）
- データベース/テーブルをALTERできない
なんとなく解ってきた気がする。 開発者はFileMakerをフロントエンド開発ツールとして使用し始めると、他ツールと比較していろいろと不便な点があることに気がつく。 特に1.データ型、2.ユーザ独自のSQLクエリが実行不能、よって、3.検索、特にソートが非常に遅くなるというのは大問題で、簡単な回避策は無い。 ところが、多くのフロントエンド開発ツールは、何の問題もなくこれらのことを実行できる。 つまり、FM社が「フロントエンドにはなりませんよ」というのは、「他のフロントエンドツールにできることでも、FileMakerではできないことがあります。 その代り、FileMakerっぽくSQLのデータをある程度なら扱えますよ。 でも、FileMaker純正データベースとは違った結果が返ることも大いにありうるので、そこら辺、凄く注意して使ってね！」というのがかなりホントのところではないかと思われる。
（土屋）
関連リンク：『売上猫くん on MySQL』開発日記の記事一覧
登録:
投稿 (Atom)