1

私は、もともと90年代に作成され、この時点でAccess2007に拡張およびアップグレードされたMicrosoftAccessビジネスクリティカルデータベースを持っています。私たちはこのデータベースを基本的にカスタム作成されたERPシステムのフロントエンドとして使用してきました。ほとんどのデータをSQLサーバーに移動しましたが、フロントエンドとしてMSAccessを使用しています。プロジェクトが成長するにつれて、私たちはフルタイムの開発者を抱えており、安定性の問題と原因不明の非常に頻繁なクラッシュが発生し始めています。

例：10回のうち1回程度、特定の1つのフィールドのデータを変更すると、特定のフォームがクラッシュします。現時点ではコードの起動はありません。データはローカルの一時テーブルにあり、通常はほとんどの場合5行しかありません。テーブルのデータを変更しても何も問題はありませんが、フォームでデータを変更すると、Accessがハードクラッシュし、デスクトップにダンプされます。原因不明のクラッシュについて私が提供できる他の例があります

この時点でどこに行くべきかについてのアドバイスを探しています。アクセスフロントエンドには、基本的に会社を運営するためのすべてのビジネスロジックがあるため、それを放棄することはできません。理想的には、フロントエンド全体を他の言語で書き直します。問題は、小さな会社として、システム全体を適切な時間枠に似た形で書き直すためのリソースがなく、他の誰かにそれを行うためのキャッシュフローがないことです。私の理想的な解決策は、アクセスフロントエンドから別のエンドポイント（Webウィンドウかローカルウィンドウか）へのある種の変換ですが、こことgoogleでの検索では、初心者のようには見えません。

したがって、基本的に私が見るすべての道は行き止まりのようです。

  • 現在のシステムを安定させるためのクラッシュの原因を見つけることができません。

  • 現在のシステムを書き直すのにかかる限り、現在のシステムでの生産を停止することはできません。

  • 新しいシステムを作成するために他の誰かにお金を払う余裕はありません。

  • 自動変換ツールはお金の無駄のようです

他のオプションはありますか、または私が考えたオプションのどれが最良と思われますか？

4

2 に答える 2

1

Access フロント エンドと SQL Server バック エンドを備えたエンタープライズ レベルのプログラムがあります。診断のためにプログラムを別々の部分に分割することは役に立たないのではないかと思います. たとえば、注文入力と在庫管理がある場合、機能ごとに 1 つのフロント エンドを持つことができます。 (はい、バックグラウンドで遠吠えが聞こえますが、それが診断目的のみである場合は役立つかもしれません...)
また、Access データベース オブジェクトをテキスト ファイルにエクスポートし、それらを新しいデータベースにインポートして取得することもできます。場合によっては奇妙なエラーを取り除きます。

于 2013-02-04T21:24:39.230 に答える
0

さて、ここで基本的な問題を言い換えると思います。スタッフにコンピューティング サイエンスの卒業生が 2 人いる場合、彼らはずっと前にアクセスの限界に達したことを予測していたはずです。私はこれを、顧客が多すぎるレストランの過労のオーブンや、顧客に商品を配達する能力のない配達用トラックと何ら変わらないとは考えていません。

書き直すための資金が存在しないため、スタッフはこの状況に対処するために毎月の資金を確保できませんでした。この増大する問題に対処するための行動が遅れた結果、あなたの選択は困難な状況に置かれています。 .

あなたがスタッフとしているコンピューティング サイエンスの担当者は、ずっと前にこの壁を見て、あなたがぶつかるのを制限していたはずです。私の経験では、ほとんどの CS の人々はアクセスがかなり制限されていると考えているため、ここでさらに多くの警報ベルが鳴っているはずであり、これは、この不幸な苦境に置かれる言い訳がさらに少ないことを意味します.

したがって、コンピューティング サイエンスのスタッフがこのアプリケーションを適切に維持していると仮定すると (そして、私はこれが事実であることを喜んで受け入れます)、論理的な結論として、このアプリケーションは Access の限界に達したか、それを超えました。前述のように、そのような制限はずっと前に予期されていたはずです。

書き直しのための資金が現在存在しないことを十分に指摘しているように、そのような資金がなければ選択肢はほとんどありません。

ただし、スタッフに経験豊富な開発者がいることがわかっているので、あなたのケースはそれほど悪くないかもしれません. この場合、私の提案は、アプリケーションからモジュールまたは小さな管理可能な部分と機能を 1 つずつ分割し、十分に訓練された経験豊富な開発者に Web インターフェイスを構築させるか、場合によっては .net のようなものを使用させることを検討することです。 100% デスクトップのままでいたい。したがって、この機会の「窓」は、アーキテクチャの変更を検討する絶好の機会です)

データの制限は SQL サーバーであり Access ではないため、両方のアプリケーション (既存のアクセス フロント エンド) と新しい部分の両方が、同じデータに対して適切かつ簡単に操作できます。これを行うと、Access アプリケーションから既存のパーツを分割して削除します。これは、最終的に Access アプリケーションでアクセス可能な安定性に戻ることを示唆しています。その時点で、資金を節約するために続行するか停止することができます。

前述のように、書き直す資金がない場合、唯一の選択肢は、この問題を解決するために、限られたリソースを毎月解放する手段を見つけることです。

結局のところ、この問題の解決策はリソースを増やすことですが、そのようなリソースがなければ、技術的な選択肢やオプションはほとんどありません。これまでに提供された情報に基づいて、あなたはここにリソースがないことを明らかにしました. ただし、ここでこの問題を解決するには、リソースの割り当てと計画が必要です。

言い換えれば、リソースを割り当てずにこの問題を技術的に修正することは、おそらくあなたにとって利用可能なオプションではありません.

ここで技術的な解決策を提供できなかったことを心からお詫び申し上げますが、これは問題にリソースを割り当てる必要がある解決策のようであり、簡単な近道やトリック、または魔法の特効薬はここにはありません。

于 2013-02-05T04:21:24.117 に答える