Ms-Access MDB：メモフィールドを複数のテキストフィールドに分割します。 （データ破損を防ぐため）

Question

バックエンドとして使用されるAccessデータベースを使用します。
メモフィールドをいくつか使用します。

メモフィールドは別のデータページに格納されているため、データベースが破損する可能性があることを学びました。レコードには、実際のデータが保存されているデータページへのポインタのみが保持されます。

ほとんどの場合、必要なのは100〜1000文字程度なので、アイデアがありました...
私の「華麗な」 （またはそうではない）アイデアは、メモを4つまたは5つのテキストフィールドに分割することでした（それぞれ255文字を保持できます）。

誰もこれをやったことがありますか？
既知の問題？
このアプローチでは、データ破損が起こりにくいでしょうか？

ありがとう、
ジャグ

P.S。
1.以前に破損の問題がありました。
2.別のバックエンドに移行するのが最善であることはわかっていますが、それは不可能です。

Answer 1

より良い回避策は、添付されたレコードからメモデータページをアンバンドルすることです。これを行う方法は、メモフィールドを別のテーブルに配置することです。 1：1のテーブル（サイドテーブルに複数のメモを含む）を使用するか、メモ型フィールドを含む1：Nテーブルとして使用することをお勧めします。後者の方法は、メモポインターの問題を完全に回避する唯一の方法ですが、前者のソリューションと同様に、メモテーブル内のメモポインターが破損すると、すべてのメモポインターが失われます。

また、データベースがメモポインターを破損している理由を考慮する必要があります。上記の提案とは別に、おそらく問題ではないJet MDBへのAccessフロントエンドを使用しているようには見えないので、メモを非バインドで編集することを検討する必要があります。メモの破損はたびたび見られますが、それほど頻繁ではありません。頻繁に表示される場合は、アプリケーションの設計が不適切であるか、オペレーティング環境が著しく標準以下であることを示唆しています。

Answer 2

既存のメモフィールドを取得して、データベースに入れる前に切り取り、表示する必要があるときに貼り付けたいと思うようです。

試してみれば、あなたは痛みの世界にいると思います。それがあなたの唯一のオプションだった場合、私はバックエンドを変更しようと一生懸命に努力します：）

あなたが提案していたようなことを提案することで、DWFの答えに基づいて構築します。 テキストフィールドを使用して1：Nテーブル（UserNotesと呼びます）を作成します（問題があると思われるメモと対比）。

次に、UserNotesをレコードソースとして含むサブフォームを作成し、メモフィールドをUserNotesサブフォームに置き換えます。これにより、ユーザーは、255文字のテキストフィールドのコンテキスト内で行/段落の区切りを決定できます。 （変換のために、メモを切り刻む必要がありますが、それは1回限りの操作です）