MS Access を MySQL データベース バックエンドのフロントエンドとして使用する際に問題がありますか?
https://stackoverflow.com/questions/5842
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
2 人のユーザーが、単一の MDB ファイルで互いに競合することなく、もともと MS Access で作成された同じデータベースを共有したいと考えていました。
私はテーブルを単純な MS Access データベースから MySQL に移動しました。 移行ツールキット (ちなみに、これはうまく機能します) そして、ODBC 経由でこれらのテーブルにリンクするように Access を設定します。
これまでのところ、次のようなことに遭遇しました。
- 主キーがなければ、テーブル内の行を挿入/更新/削除することはできません (当然のことですが)。
- MS Access の AutoNumber フィールドは主キーでなければなりません。そうしないと、MySQL では単なる整数列になってしまいます (おいおい、なぜそれが PK ではないのでしょう?)
- テーブルは MySQL の InnoDB テーブル タイプに移行されましたが、Access リレーションシップは MySQL 外部キー制約になりませんでした。
データベースを使用すると、他に問題が発生する可能性がありますか?特に両方のユーザーが同じテーブルで作業している場合はどうですか?
解決
同様に動作するアプリケーションがありました:MS Access フロントエンドから MySQL バックエンドへ。とても面倒だったので、代わりに Win32 フロントエンドを書くことになりました。頭のてっぺんから、次の問題に遭遇しました。
- ODBC リンクの開発はかなり前に中止されたようです。さまざまなバージョンが存在しており、非常に混乱しています。ODBC リンクは Unicode/UTF8 をサポートしていません。また、他にも問題があったことを覚えています (ただし、一部は慎重に構成すれば解決できます)。
- おそらく、データベース スキーマを手動で調整して、MS Access と互換性を持たせることが必要になるでしょう。必要な代理キー (つまり、int 主キー) についてはすでにわかっているようです :-)
- MySQL データベースのより高度な SQL 操作を行うには、パススルー クエリの使用が必要になる場合があることに留意してください。
- VBA を多量に使用すると、フロントエンド ファイルが破損する傾向があるので注意してください。定期的にデータベースを圧縮し (メイン メニューの [ツール] | [データベース ユーティリティ] | [圧縮と復元] などを使用します。--- 私はオランダ語版を使用しています)、 たくさん のバックアップが必要です。
- アクセスすると、大量のネットワーク トラフィックが発生する傾向があります。本当に広大な敷地です。それに対する解決策を見つけることができませんでした。監視したい場合はネットワークモニターの使用がおすすめです！
- Access はブール値を 0/-1 として保存することを要求します。私の意見では、0/+1 の方が合理的であり、MySQL でもそれがデフォルトの方法であると思います。大きな問題ではありませんが、チェックボックスが機能しない場合は、必ずこれをチェックしてください。
考えられる代替案の 1 つは、バックエンド (データを含む) を共有ドライブに配置することです。これについてはヘルプにも詳しく記載されていると記憶しています。見てみるのもいいかもしれません フロントエンドとバックエンドへの分割に関する一般的なアドバイス そして 起動時にバックエンドに自動的に再接続するコード;さらにサンプル コードをお送りするか、ここに投稿することもできます。
それ以外の場合は、MS SQL を検討することもできます。私には経験がありませんが、MS Access と併用するとよりうまく機能すると思います。
他のヒント
このトピックがそれほど新しいものではないことは承知していますが、いくつかの追加説明があります。
特に大規模なマルチユーザー データベースで MS Access を効果的に使用したい場合は、次の手順を実行してください。
MDB をフロントエンド アプリケーション ファイルとバックエンド (データのみ) ファイルに分割すると、2 つの別々の MDB ファイルが作成されます。
データと構造を含むすべてのテーブルを外部データベースに移行します。かもね：MySQL (非常にうまく機能し、データベース サイズの制限はありません。MS テクノロジではないため、さらにスキルが必要ですが、多くの場合、これが良い選択です。さらに、より多くの RAM と追加の CPU でバックエンドを拡張できるため、すべてはニーズに応じて異なります)およびハードウェア機能)。Oracle (十分な資金または何らかの企業ライセンスがある場合) または Oracle 10g XE (これが問題にならない場合、データベース サイズは最大 4 GB に制限されており、常に 1 GB の RAM と 1 CPU を使用します)、 MS SQL Server 2008 (あらゆる場合に MS Access フロントエンドと MS SQL Server バックエンドを備えた優れた組み合わせですが、ライセンス料を支払う必要があります。- 利点は次のとおりです。緊密な統合により、両方のテクノロジーが同じベンダーから提供されます。MS SQL Server は、同時に効果的なものを維持するのが非常に簡単です) または Express エディション (Oracle XE と同じ話 - ほぼ同じ制限)。
MS Access フロントエンドとバックエンド データベースを再リンクします。バックエンドとして MS SQL Server を選択した場合は、MS Access のウィザードを使用するのと同じくらい簡単です。MySQL の場合 - ODBC ドライバーを使用する必要があります (シンプルで非常にうまく機能します)。Oracle の場合 - Microsoft の ODBC ドライバーを使用しないでください。Oracle のこれらは、より効率的に動作します (Oracle ODBC ドライバーと MS Oracle ODBC ドライバーを介して MS Access から Oracle へ SQL クエリを実行するのに必要な時間を比較できます)。この時点で、堅牢なデータベース バックエンドと完全に機能する MS Access フロントエンド (MDB ファイル) が完成します。
MDB フロントエンドを MDE にコンパイルすると、速度が大幅に向上します。さらに、これは MS Access アプリケーションをエンド ユーザーに配布する唯一の合理的な形式です。
日常の作業には、MS Access フロントエンドで MDE ファイルを使用します。今後の MS Access フロントエンド開発には、MDB ファイルを使用してください。
MS Access フロントエンド機能を強化するために、不適切に作成された ActiveX コンポーネントを使用しないでください。自分で書くか、適切なものを購入した方がよいでしょう。
MS Access には多くの問題があるという通説を信じないでください。これは、あらゆる場面で役立つ素晴らしい製品です。問題は、多くの人が MS Access がおもちゃであるか、または MS Access が一般的に単純であると考えていることです。通常、彼らは自分自身と知識と経験の不足によって多くのエラーや問題を引き起こします。MS Access で成功するには、このツールを理解することが重要です。これは、他のテクノロジーと同様、同じルールです。
私は MySQL バックエンドに合わせて非常に高度な MS Access を使用していると言えますが、(このアプリケーションを保守している開発者として) 非常に満足しています。友人の皆さん、ユーザーも GUI (フロントエンド) や速度 (MySQL) に非常に満足しており、レコードのロックやデータベースのパフォーマンスに問題はなく、満足しています。
さらに、優れた実践方法や他の人の経験についてたくさん読むことが重要です。多くの場合、MS Access が適切なソリューションであると言えます。私は、プライベート MS Access データベース (MDB ファイル) の形式で実験として始まり、その後次のように進化した専用のカスタムメイド システムを多数知っています。分割された MS Access (MDE - フロントエンド、MDB - バックエンド)、そして最終的に:MS Access フロントエンド (MDE) と「本格的な」データベース バックエンド (主に MS SQL Server と MySQL)。MS Access ソリューションを常に動作するプロトタイプとして使用できることも重要です。データベース (MySQL - 仮定します) でバックエンドを使用する準備ができており、フロントエンドを選択したテクノロジ (Web ソリューション?) に書き換えることができます。おそらくデスクトップ C# アプリケーション - 必要なものです!)。
MS Access での作業を検討している方のお役に立てれば幸いです。
よろしく、Wawrzynhttp://dcserwis.pl
ギャレス・シンプソンはこう意見した。
ユーザーが2人しかいない場合は、.mdbを共有ドライブに配置すると、アクセスが正常に行われるはずです。
えー、いえ。各ユーザーがフロント エンドの専用コピーを持つ必要のないマルチユーザー Access アプリケーションはありません。つまり、各ユーザーは自分のワークステーション上に MDB を持っている必要があります。なぜ？フロントエンドのオブジェクトがうまく共有されていないためです (ただし、このシナリオではバックエンドとして MySQL を使用しているものはありませんが、Jet データ テーブルほどではありません)。
ギャレス・シンプソンはこう続けた。
推奨されるMax Concurrentユーザーは5であると思いますが、たまにこれをプッシュして、決して停滞しません。
いいえ、これは完全に間違いです。MDB のユーザーの理論上の制限は 255 です。もちろん、これは現実的ではありません。ユーザー数が 20 人程度になると、Access アプリがうまく機能するように慎重にプログラムする必要があるからです (ただし、Access-to-Jet アプリで行う必要があることは、Access-to-Jet アプリで行う必要があることと同じ種類です)。サーバー データベース アプリケーションを効率的にするために実行します (例: 使用可能な最小のデータ セットを取得するなど)。
この場合、各ユーザーはフロントエンド MDB の個別のコピーを持つ必要があるため、Access/Jet のマルチユーザー制限は全く関係ありません。
これがあなたの質問に直接答えていないことは承知していますが、チェックしてみる価値はあるかもしれません。 Access 用の SQL Server 2005 移行ツール. 。このツールを使用したことはありませんが、SQL Server 2005 Express Edition で使用して、MySQL で発生したのと同じ問題があるかどうかを確認する価値はあるかもしれません。
各レコードに何らかのタイプの時刻/日付スタンプを付けることを忘れないでください。ms access は、「別のユーザーがレコードを変更または削除した」と判断し、変更を許可しないことがあります。私はこれを苦労して見つけました。
一般的に、それは状況によります:)
アプリケーション側がフォームを通じてデータを更新しているだけの場合は、あまり問題はありませんでした。同じ行が複数のユーザーによって更新された場合、警告/エラーが発生することがあります。しかし、Access はライブ レコード セットを常に更新し続けているようです。
アリスがすでにレコード 365 を使用していて、ボブがそれを更新し、アリスが自分の変更でレコードを更新しようとすると、問題が発生する可能性があります。私の記憶では、Alice は不可解なエラー メッセージを受け取ります。これらのエラーをトラップし、少なくともわかりやすいエラー メッセージを表示すると、ユーザーが使いやすくなります。
RecordSet を使用して VB コード内のレコードを編集しているとき、特にフォーム上の同じデータの編集と組み合わせたときに、さらに問題が発生しました。これは必ずしもマルチユーザーの問題ではありません。ただし、1 人のユーザーが同じデータに複数の接続を持っているため、ほぼ同じ状況になります。
ユーザーが 2 人だけの場合は、.mdb を共有ドライブに配置すれば、Access は問題なく動作します。
問題があるだろうと思い込むのではなく、まず試してみましたか。
Access の推奨最大同時ユーザー数は 5 人だと思いますが、時々これを超えても問題が解決することはありません。
一方、私はシングル ユーザー環境 (私) で MySQL のフロント エンドとして Access を使用したことがあります。それは非常に不快な経験でしたが、ユーザーが 2 人になったらもっと快適になるとは想像できません。
