このアプリケーションは Lotus Domino サーバーに接続し、そのデータベースで動作します。クライアントのサーバーの 1 つで、Lotus Notes クライアントで開くことができない破損したデータベースを確認したことがあります。残念ながら、コピーを依頼する前にクライアントのスタッフが削除してしまいましたが、この種の破損したデータベースでもアプリケーションのエラー処理をテストしたいと考えています。
また、正常なデータベースのランダムなバイトを 16 進エディタで変更して、データベースを破損させようとしましたが、成功しませんでした。破損したデータベースまたは自由にダウンロードできるデータベースを作成する方法を探しています。
IBMはNSFファイルの詳細な内部構造を文書化していないため、破損したデータベースをシミュレートするための優れたガイドは実際にはありません。
ただし、すべてのバイトをゼロに変更すると、データベースが非常に破損します。アプリケーションの動作をテストすることは特に有用ではありません。これは、クライアントのサーバーで見たのと同じタイプの破損ではない可能性があります。
NSFが破損する可能性のある方法はたくさんあります。一部はサーバーによって自動的に修正されます。データベースを開くことができない場合もあります。データベースを開くことはできても、読み取りや更新が行われないようにするものもあります。API呼び出しによって返されたデータが失われたり、壊れたりする原因となる場合があります。一部の場合、NotesAPIコアDLLがクラッシュします。考えられるすべての種類の破損について、コードの動作をテストすることは実際には不可能だと思います。とにかく、妥当な数のテストケースではありません。（つまり、最小サイズのNSFでゼロ以外の個々のバイトの1つをランダムにゼロにする約1,000のケースでは、考えられるさまざまな種類の損傷のほとんどを与える可能性が高いと推測しています。）
Lotus Notes/Domino データベースの内部構造は、コンテナー モデルとして最もよく説明されています。内部のデータを取得するには、ACL (アクセス制御リスト) によって保護されているデータベース コンテナーにアクセスする必要があります。内部のほとんどすべてが「ドキュメント」であり、UNID によって識別される一意のレコードです。これらの「ドキュメント」には、フォーム、エージェント、ビュー (およびその ACL) などの設計要素もあれば、実際のデータ レコードもあります。破損には、これらの破損の 1 つまたは複数が含まれます。破損の内容と破損の程度は、データベースを開こうとしたとき、または Web、Notes クライアント、またはサード パーティのソフトウェアを介してデータベースにアクセスしようとしたときに発生するものによって異なります。
上記を考えると、テスト用に「破損した」データベースを作成しようとしてもあまりメリットがありません。これを有効にするには、どのビットを壊しているかを知る必要があるからです。IBM はこれを保護し、代替のノーツ クライアントを構築することを望んでいないため、常にこの専有情報を保護します。
最後に付け加えておきますが、ほぼ 15 年間の Notes 開発作業の中で、破損に遭遇することはめったにないため、めったに発生しない破損を分析するコードを作成するビジネス ケースはほとんどないということです。ほとんどの場合、これで十分です。