5

私は、Access 97 アプリケーションを使用してバックエンド データを SQL Server に移動し、フロント エンドを Access 2003 に移動する (Access Data Projects を使用) という任務を負っています。この移行の過程で、新しい機能をサポートするためにバックエンドのデータ構造が大幅に変更されます。

私が望むなら、Access をフロント エンドとして使用することはありません。私たちのアプリケーションは、WinForms、WPF、または Web アプリケーションの方がはるかに優れていると思います。ビジネス ロジック層を適切に計画し、優れたソリューションを実装するのに必要な時間はありますが、私より上の権限は Access にとどまりたいと考えています。

私がヘルプを使用できるのは、Access 開発のこの道を進むことの賛否両論です。Access 2003 の使用に賛成または反対する正当な理由は何ですか? これが私がこれまでに思いついたものです。

プロ アクセス:

  1. 既に Access 2003 ライセンスを所有している
  2. 簡単な GUI 開発
  3. レポートは見栄えが良い

アクセスに対して

  1. VBA (Visual Basic for Applications) を使用する必要がある
  2. ADO 対 DAO。Microsoft は Access 2002 から Access 2003 に変更しませんでしたか?
  3. Access ランタイムに関連付けられていない
  4. フロントエンドでの選択 (WPF、WinForms、さらには ASP.NET)
  5. 保守性
  6. UI からロジックを完全に分離することは不可能
  7. Microsoft は引き続き Access ADP をサポートしていますか?

おそらく、Access for application development の賛成派と反対派の両方について、私が認識していない問題が他にもあるでしょう。私は心を開いたままにしようとしていますが、同時に正気を維持しようとしています。

.NET がリリースされてからずっと C# を使用しており、6 か月間 VBA に戻ると考えると頭が痛くなります。特に、最新の言語とツールを使用した開発が許可されれば、もっと多くのことを提供できると感じたときは?

4

5 に答える 5

6

ADP は、孤立したインターフェイスである ADO Classic (OLEDB のラッパー) を中心に構築されており、今後開発される予定はありません。A2007 と A2010 では、ADP は変更されていません。これは、MS がデータ アクセス ページ (DAP) で行われたことを行うかどうかを評価している可能性が高いことを示しています。それらを完全に (A2007)。

ただし、MS が ADP について何らかの対策を講じる可能性もあります。最近、Access チームがブログで、Access で SQL Server を使いやすくするために変更できる点について、SQL Server ユーザーからのフィードバックを求めているためです。そのフィードバックは、Access の次のバージョンの 1 つ (A2010 以降または次のバージョン) に反映されます。これは、ADPs の開発の復活という形をとるかもしれませんし、まったく異なる形をとるかもしれません。Access チームは Access と Sharepoint の統合にかなり熱心に取り組んでいるため (大きな効果があるため、私は付け加えます)、Sharepoint が SQL Server の上に構築されていることを考えると、後者を期待します。 SQL Server の「問題」を解決します。

しかし、ここには内部情報はまったくありません。

現在のケースでは、既存の MDB が既に開発されています。既存の MDB を ADP に移植するのは、実際には単純なプロセスではありません。SAVE AS を実行するだけではなく、変換ルーチンもありません。これは、ADP と MDB がまったく異なる動物であるためです。MDB は Jet データベースですが、ADP は Jet を使用しないコンテナ ファイルです。たとえば、ADP 内のオブジェクトは、MDB 内のオブジェクトと同じプロパティや動作を持っているとは限らないため、単にインポートすることはできません。

したがって、ADP に「変換」するには、ほぼ完全に書き直す必要があり、その難易度は、私の意見では、WinForms やその他のまったく異なるプラットフォームへの移植と同程度です (ただし、ADP やその他のプラットフォームを使用したことはありません)。 WinForms であるため、ここでは誤った見積もりをしている可能性があります)。私が知っていることは、ADP と MDB が十分に異なっているということです。両方とも Access であるという事実は、何らかの形で相互に互換性があるか、変換可能であると誤って示唆していますが、そうではありません!

Access ADP の将来が不確実であることを考えると、既存の MDB アプリを ADP に変換することは言うまでもなく、その形式で新しい開発に着手することはお勧めしません。

私にとって、それは非常に簡単です.A2003に変換し、プロセスにほとんどまたはまったく時間を費やさずにそれを完了してください.

見返りが大きい場合にのみポートを検討しますが、Access アプリケーション自体の欠点のリストを提供していません。タイムラインをもう少し延長して、このアプリケーションの寿命を検討してください。また、Sharepoint 2010 と統合された Access 2010 の新機能と、Access でフロント エンドを開発し、それを Web ブラウザーで実行できる Access Services についてもよく理解する必要があります。これにより、ランタイムが不要になり、大きな助けになります。

しかし、既存のクライアント アクセス アプリを Web アクセス アプリに簡単に変換することはできません。ただし、何が機能し、何が機能しないかを示す互換性チェッカーがあるため、変換をガイドする補助輪がまったくないわけではありません.

アプリの全体像とその寿命、および Access と Sharepoint の将来を考慮に入れると、まったく異なる一連の答えが思いつくかもしれません。

また、Access が VBA に永久に結び付けられるわけではないことにも注意してください。私は、A2010 以降の次の 2 つのバージョンの Access のいずれかで、何らかの形で .NET が統合されることを完全に期待しています。一方、新しいマクロ (現在はエラー処理と完全な分岐構造を備えています) を使用すると、MS が任意のアドホック スクリプト言語を Access から削除し、プログラミング用に大幅に強化されたマクロのみを提供する可能性があります。

MS が 5 ～ 10 年後に Access でどの方向に進むかを確実に知ることは不可能ですが、過去 2 つのバージョンで Access に多額の投資が行われたことはわかっており、Access の将来は SharePoint 統合と密接に結びついています. それを知っていれば、長所と短所の相対的なバランスについて別の結論に達するかもしれません。

于 2010-05-03T22:16:38.613 に答える
1

会社の開発ツールを変更しようとするときは、会社の視点から見てください。おそらく、Access で働いていたマネージャーが何人かいるでしょう。ピンチでは、彼らが飛び込んで問題を修正するなどの可能性があります。保守性は企業にとってのみ意味があり、個人にとっては意味がありません。強力な Web アプリを作成しても、企業内に開発ツールの経験者が誰もいない場合、その企業には、何か問題が発生したときに飛び込むことができる開発者が 1 人しかいないため、良くも悪くも悪くなります。誰かが病気になるなど。

2003 ではなく最新バージョンの Access にアップグレードする必要があるという HLGLM に同意します。

複数の開発者がいる場合、Access にネイティブ構成管理 (バージョン管理) がないことは、Access に対する強力な反論となります。

于 2010-05-03T22:35:15.710 に答える
1

ADP は引き続きサポートされていますが、多くのバージョンで大幅な機能強化は行われていません。したがって、アプリを Access 2003 以降にアップグレードし、ランタイムを使用してクライアント ワークステーションで動作させることをお勧めします。Access 2007 ランタイムは無料です。

次に、バックエンドを SQL Server にアップワイズし、Access データベースを MDB 形式に保ちます。Access のボトルネックを取り除き、パフォーマンスを向上させるために必要なビューとストアド プロシージャを作成します。どの方向に進んでも、これらのビューとストアド プロシージャが必要になります。

データベースのアップサイジング中に機能を追加 しないでください。まずはスムーズに動かしてください。

この時点で、あなたとその権力は、あなたがどの方向に進みたいかを決めることができます.

Access にとどまる場合は、新しい機能を少しずつ追加します。これらの更新をユーザーが毎週利用できるようにします。または、より頻繁に私がしていることです。

于 2010-05-04T20:39:28.300 に答える
0

私はこれに非常に遅れているので、記録のためだけに: ADP では、複数のサーバーに接続することはできません。それはショーストッパーになることができます！

于 2011-05-02T13:45:11.887 に答える
0

私に関する限り、Access (およびその新しいバージョン) を使い続ける唯一の理由は、フロント エンドの機能に変更を加えず、スケジュールが非常に厳しい場合です。しかし、データベースを再構築して一部の機能をやり直す場合、Access を使い続けることは私には意味がありません。バックエンドの SQL サーバーを作成するだけではパフォーマンスの問題は解決しません。Access Jet エンジンの代わりにストアド プロシージャを使用するように変換する必要があります。

プログラミングに精通しているものをプロジェクトのコスト削減として使用するというアイデアを、Access を学ぶために戻って売り込むことはできますか? おそらく、見積もり時間を数か月短縮できれば、Access を避ける十分な理由になるでしょう。

Access に行き詰まっている場合は、少なくとも新しいライセンスを購入して最新バージョンを使用するように依頼してください。古いバージョンに「アップグレード」するのはばかげています。

レポートの見栄えに関しては、SQl Server には非常に優れたレポートを作成するレポート ツールもあります。SSRS でいくつかのレポートを生成し、それらがどれほど優れているかを示します。変更の展開は、Web ベースのアプリケーションの方が簡単です。以前のバージョンの Access を展開するのは難しいと確信しています (ここで私の記憶を掘り返します)。私が思い出すと、あなたはDDL地獄に行き着きます。それを避けるのに十分な理由があります。Web ベースのアプリ (彼らはイントラネットを持っていますよね?) の展開は簡単で、すべてのユーザーが一度に展開され、すべてが機能します。また、もう 1 つの典型的な Access の問題である、古いバージョンのフロント エンドで作業している人もいません。

Access ではできないようなダッシュボードを備えた Web アプリのおしゃれなプロトタイプを見せてください。Access をやめた場合に得られる機能をユーザーに欲しがらせます。

于 2010-05-03T19:55:35.590 に答える