プロジェクトを XE6 IDE にロードすると、次のエラーが発生することがあります。
このエラーにより、TZConnection コンポーネントが何らかの不可解な理由で Datamodule から削除されます。プロジェクトは何年にもわたって問題なく読み込まれており、突然、これが発生することに注意してください。
誰もこれを前に見て、それを止める方法を知っていますか? また、他のコンポーネントでも発生します。常に TZConnection コンポーネントではなく、ほとんどが ZConnection コンポーネントです。
前にも言ったように、これはランダムに表示されます。プロジェクト A を閉じて、プロジェクト B を開いてから閉じて、プロジェクト A に戻って bang! を実行すると、エラーが発生します。
手がかりはありますか？（これは Delphi 2007 でも発生していたことに注意してください）
実際には、それほど説明できないようには聞こえません。おそらく、 DataModule (またはプロパティを介して接続された db 対応コンポーネントを含む何らかのフォーム) が IDE に読み込まれているときに例外が発生したことが原因です (以下を参照)。ZEOS .BPL ファイルがある場所がシステム パス上にあることを確認してみましたか? 同様に、それらが依存する .BPL - Zeos の .DPK ファイルの「requires」句を参照してください。
この種の問題は、不安定な DB コンポーネントでかなり頻繁に発生します。たとえば、フォーム上の db 対応コンポーネントがデータモジュール上の他のコンポーネントに接続されている場合など、db コンポーネントはデータモジュールとフォーム間のリンケージをより頻繁に伴うため、他のタイプのコンポーネントよりもおそらくそうです。
そのため、この種の問題が発生するかどうかは、IDE がそれらを再度開く順序に依存する場合があります。dm のみを開いた状態でプロジェクトを閉じてから、再度開いてみてください。IDE でどのデータモジュールとフォームが開いているか、どの順序で開いているかを少し試してみると、問題を突き止めるのに役立つ場合があります。問題を引き起こすための再現可能な一連の手順がある場合は、作成者に報告してください。
プロジェクトのロード時に問題が例外によって引き起こされているかどうかを判断するかなり信頼できる方法は、IDE の 1 つのインスタンスを別のインスタンス内で実行することです。IDE の最初の (「外側」) インスタンスのデバッガーが「言語例外で中断」に設定されている限り、プロジェクトが実行されたときに例外のソースに直接移動できるはずです (もちろん、例外が発生すると仮定します)。 2 番目のインスタンスによって読み込まれます。もちろん、「その行為でそれをキャッチする」には数回かかる場合がありますが、なんとか成功したときは非常に満足です. 幸運を！
MartynA とは異なり、これが例外によって引き起こされるとは思えません。
windows path environment variableこのような問題は、長すぎることが原因であると予想される可能性が高くなります。
残念ながら、依然として多くのコンポーネント ベンダーや一部のプログラムでさえ、「Windows パス環境変数」を変更して、独自のファイルを他のプログラムからアクセスできるようにしています。
十分な情報を提供できない場合windows path environment variable、ウィンドウはデフォルトのシステムディレクトリでファイルを見つけようとします。C:\Windows\System32
windows path environment variableそのため、をチェックして長さを確認することを強くお勧めします。
これを行う最も簡単な方法は、ディレクティブを開始しcommand promptて入力するか、パス環境変数情報をファイルにエクスポートして、長い場合に読みやすくすることです。pathpath >> D:\path.log
EDIT：ところで、パス環境変数を確認したところ、Delphi XE8とDelphi XE 10の両方のシアトルファイルの場所のエントリが含まれているため、コンピューターからDelphi XE8を削除したにもかかわらず、いくつかのクリーニングを行う必要があることがわかりました。かなり前に削除したいくつかのプログラムからのいくつかのエントリは言うまでもありません。