より広いStackOverflow人口を引き付けるタグを持つMS-ACCESSの質問の場合はほとんどの場合そうであるように、答える人々はここで重要な質問を見逃しているように思われます。
Accessアプリケーションを他のプラットフォームに正常に変換できるツールはありますか？
そして答えは
絶対違う
その理由は、UIオブジェクトに同様のモデルを使用する同じファミリのツール（VB6など）には、Accessがデフォルトで提供するものが非常に少ないためです（Accessの連続サブフォームをVB6に変換し、機能を失わないようにするにはどうすればよいですか？ ）。また、他のプラットフォームはVB6やAccessと同じコアモデルを共有していないため、クリアする必要のあるハードルがさらに高くなります。
引用されたMySQLの記事は非常に興味深いものですが、開発が不十分なアプリに伴う問題と、使用されている開発ツールに伴う問題を実際に混同しています。不正なデータスキーマはAccessに固有のものではなく、[ほとんどの]初心者のデータベースユーザーに固有のものです。しかし、記事はこの問題をAccessに起因しているようです。
そして、スキーマを修正し、MySQLにアップサイジングし、フロントエンドをAccessに維持する可能性を完全に見落としています。これは、この問題への最も簡単なアプローチです。
これは、Accessを取得できない人々に私が期待していることです。彼らは、Accessをセキュリティで保護された大容量サーバーデータベースエンジンのフロントエンドとして問題の優れたソリューションにできるとは考えていません。
その記事では、Accessアプリの変換についても実際には考慮されておらず、それには十分な理由があります。Accessアプリケーションを（どのプラットフォームにも）変換すると主張するすべてのツールは、データのみを変換するか（この場合、アプリをまったく変換しません-morons！）、またはフロントエンド構造をスラブに変換します、AccessアプリケーションとターゲットアプリのUIオブジェクトが1：1で対応しています。
これは機能しません。
Accessのアプリケーション設計はそれ自体に固有であり、他のプラットフォームは同じ機能セットをサポートしていません。したがって、Access機能を、変換されたアプリケーションの元の機能の代わりに機能するように変換する必要があります。私の意見では、これは自動化された方法で実行できるものではありません。
次に、AccessアプリをWebブラウザーにデプロイするために変換することを検討している場合、アプリケーションモデル全体が異なります。つまり、ステートフルからステートレスになります。したがって、サポートされていないいくつかのAccess機能だけでなく、完全に異なるものです。 UIオブジェクトがデータとどのように相互作用するかの基本モデル。おそらく、100％バインドされていないAccessアプリは、比較的簡単にブラウザーベースの実装に変換できますが、そのうちのいくつがありますか？これは、サブフォームをまったく使用しないAccessアプリ（バインドを解除できないため）と、リッチイベントモデルの少数のイベントのみを使用するアプリ（ほとんどはバインドされたフォーム/コントロールでのみ機能する）を意味します。つまり、100％バインドされていないAccessアプリは、Access開発パラダイム全体と戦うものになります。Accessでバインドされていないアプリを作成したいと思っている人は、そもそもAccessを使用するべきではありません。Accessの全体的なポイントはバインドされたフォーム/コントロールだからです。これを排除すると、他の開発プラットフォームに対するAccessのRADの利点の大部分が失われ、見返りとしてほとんど何も得られません（コードが非常に複雑になることを除けば）。
Accessアプリケーションと同じタスクを実行するWebブラウザーにデプロイするアプリを構築するには、アプリケーションのUIとワークフローをゼロから再設計する必要があります。成功したAccessアプリケーションモデルは成功したWebアプリケーションモデルとは正反対であるため、機能する変換や変換はありません。
もちろん、このすべての変更は、Access2010およびSharepointServer 2010 withAccessServicesで行われます。その場合、Accessで（Webオブジェクトを使用して）アプリをビルドし、Sharepointにデプロイして、ユーザーがブラウザーで実行できるようにすることができます。結果は機能的に100％同等（および視覚的に90％）であり、すべてのブラウザーで実行されます（ここではIE固有の依存関係はありません）。
したがって、今年の6月以降、ブラウザーでの展開用にAccessアプリを変換する最も安価な方法は、A2010にアップグレードし、すべてのWebオブジェクトを使用するように設計を変換してから、Sharepointで展開することです。Access Webオブジェクトはクライアントオブジェクトと比較して機能のセットが限られているため、これは簡単なプロジェクトではありません（たとえば、VBAがないため、古いマクロよりもはるかに強力で安全な新しいマクロを学習する必要があります。これは、Accessのレガシーマクロに精通している人にとってはひどい困難ではないように思われるかもしれませんが、Webに展開するための本格的な再設計よりもはるかに少ない作業である可能性があります。
もう1つは、AccessクライアントでもWebブラウザーでも同じであるため、エンドユーザーの再トレーニングが不要なことです（Webオブジェクトのバージョンは元のクライアントのバージョンと同じであるため）。
つまり、変換はキメラであり、ほとんどの場合、努力する価値はありません。実際、私は引用された感情に同意しています（そのソースからの他のコメントに多くの問題がある場合でも）。しかし、私はまた、変換の欲求が誤って導かれ、Accessアプリを上から下に大規模に交換する必要のない、より安く、より簡単で、より良いソリューションを見逃していることにも注意します。データストアとしてのJet/ACEに対する不満は、Accessアプリケーションも置き換える必要があると人々を混乱させることがよくあります。そして、多くのユーザー開発のAccessアプリは、ひどい、保守不可能な妥協点で満たされ、チューインガムとベイルワイヤーでまとめられているのは事実です。
それはそれが簡単だという意味ではありません-それは非常にしばしばそうではありません。私がいつもクライアントに言っているように、古い家を改造するよりも新しい家を建てる方が通常は簡単です。しかし、私たちが古い家を改造する理由の1つは、私たちが失いたくないかけがえのない特性を持っているからです。Accessアプリには、新しいアプリ（古いNetscapeの難問、ペースJoel Spolsky）で失われてはならない多くのビジネスルールとワークフローのモデリングが暗黙的に含まれていることがよくあります。これらのことは、別のプラットフォームに移植しようとしている外部の開発者には明らかではないかもしれませんが、エンドユーザーにとって、アプリが古いアプリと比較して1ペニー離れた結果を生成する場合、それらは不幸になります（そしておそらくあるべきです、
とにかく、私はあまりにも長い間歩き回っていましたが、私の意見では、最も些細なアプリ（または変換されるように設計されたアプリ、たとえば100％アンバウンドAccessアプリ）を除いて、変換は機能しません。私はすべて、交換の代わりに改訂する必要があります。
しかし、もちろん、それが私の生計を立てている方法です。つまり、Accessアプリを修正する方法です。