Microsoft Access Club Access超初心者対象Forum Access初・中級者対象Forum Access VBA Tips Forum DAO、ADO、SQL Forum

     

リストへもどる

投稿記事の一括表示

タイトルメモ型フィールドへWordのデータ貼り付け→修正できない
記事No83169
投稿日: 2017/11/06(Mon) 16:30
投稿者しま
解決済: ON
OS:Windows7
Access Version:14.0.7188.5002 (Access 2007-2010)


初めまして。
見よう見まねでデータベースを作成し、顧客情報等の管理に運用しています。

対応記録テーブルに対応記録ID、顧客ID、日付、時間、主な内容(テキスト型)、内容詳細(メモ型)フィールドを作り、顧客情報フォームから顧客IDで新規対応入力フォームを立ち上げ、対応記録を入力して保存しています。

また、その後に修正する場合は別途修正フォームで編集を行っています。

普通に入力フォームから入力して保存する分には何も問題はないのですが、たまにWordで作成した長文をコピーして入力フォームに貼り付けると、保存はできるのですが、その後の修正ができません。
(修正フォームで、テキスト自体を書き換えることはできるのですが、それを上書き保存してもテーブル内のデータに反映されていません。→ Wordデータの貼り付けの場合以外は、この方法で上書き保存が出来ています。)

ちなみに、関係があるか分からないのですが、
対応記録テーブル>内容詳細フィールドのプロパティは、下記のようになっています。

書式:空欄
標題:空欄
既定値:空欄
入力規則:空欄
エラーメッセージ:空欄
値要求:いいえ
空文字列の許可:はい
インデックス:いいえ
Unigode圧縮:はい
IME入力モード:オン
IME変換モード:一般
ふりがな:空欄
住所入力支援:空欄
スマートタグ:空欄
文字書式:テキスト形式
文字配置:標準
追加のみ:いいえ

となっています。
ACCESS側の設定の問題なのか、Wordのテキストの形式?が制限されているのかも分からず・・。

以前、似たようなトラブルがあった方は、インデックスが「はい」になっていたようですが、こちらは「いいえ」となっているので、また別の問題なのかなと思います。

どなたかお詳しい方がいらっしゃったらご教授いただけますとうれしいです。

よろしくお願いいたします。

タイトルRe: メモ型フィールドへWordのデータ貼り付け→修正できない
記事No83181
投稿日: 2017/11/20(Mon) 10:16
投稿者しま
解決済: ON
お世話になります。質問者です。

引き続きこの件で困っており、色々試してみました。



これまで、修正ができなくなる不具合が発生したのは、



・A4サイズ2ページ以上の文字量となるテキストデータ。

・Emailメッセージのコピーデータ。



です。



いずれも、入力フォームや修正フォームに貼り付け→保存を行いテーブルに格納すると、

それ以降、修正フォームから修正をしようとしても、画面上は修正できているのですが、保存コマンドボタンを押してもテーブル上のデータに反映されています。

(ちなみに、他のデータについては修正し、保存ボタンで反映されますので、コマンドボタンの不具合ではなさそうです)



さらに、該当データをテーブル上で直接書き換えてみたところ、こちらは修正できました。

ですので、データそのものの問題でもないように思います。



また、ためしに新規のデータベースを作って、同じWord文書、E-mailからのデータを入力してみたところ、こちらは修正ができました。

つまり、長文データは修正できないなどの、Accessの仕様の問題でもなさそうです。





引き続き、有識者の方からの助言をお待ちしています。よろしくお願いいたします。

タイトルRTF と TXT
記事No83192
投稿日: 2017/11/21(Tue) 16:04
投稿者mayu
解決済: ON
MS-WORD の入力インターフェースは
書体・センタリングなどのレイアウト・色などを変えたりできる{ リッチテキスト }です。
※ ワードパットも RTF、メモ帳は TXT

メーラーのメッセージ形式は、何らかのポリシーで形式を制限しないかぎり
プレーンテキスト・リッチテキスト( html )どちらなのかは利用者の設定に依存します。

それに対して、しまさんが作成したデータベースの環境は
> 文字書式:テキスト形式
なのですよね。

リッチテキストは、画像データが含まれていることもあり
文字列以外の情報も多く含む性質上、容量も大きくなりがちで
データ転送元のインターフェースが リッチテキスト形式 である場合は
データ転送先のインターフェースも リッチテキスト形式 でないと
正確にデータが送受信できませんし、編集も不可となり、場合によっては表示も崩れます。
( MS-Access に限った話ではありません )

以上のことから、ビジネスマナーとして
メールは(プレーン)テキストが推奨されている理由の一つになっています。

長文を入力するのでしたらなおのこと

 ・ 可読性が高い
 ・ 軽い
 ・ 環境依存しない

という長所があるプレーンテキストで入力データを統一するよう
利用者へお願いすることが、DBA の役割でもあり、王道ではないかと思います。

Accessでのメモ型( 長いテキスト )の文字書式は
テキスト・リッチテキスト どちらも選択可能ですので
最終手段として、テーブルの書式・フォームのテキストボックス共に
リッチテキストに設定してはいかがでしょうか。

なお、今回のケースに該当しているとは思えませんけど
https://support.office.com/ja-jp/article/Access-2016-%E3%81%AE%E4%BB%95%E6%A7%98-0cf3c66f-9cf2-4e32-9568-98c1025bb47c
テキストボックスへの文字数 65,535 という制限は存在します。

タイトルRe: RTF と TXT
記事No83193
投稿日: 2017/11/22(Wed) 16:11
投稿者しま
解決済: ON
mayuさま

とても分かりやすいご説明をいただきありがとうございます。

早速テーブルのメモ型フィールドおよび各フォームのメモ型テキストボックスで
テキスト形式をリッチテキスト形式に変更してから
今回相談させていただいた件で同じ操作をしてみたのですが、
残念ながら状況は変わりませんでした。


(もともと、新規データベースを作って同じデータを貼り付けたときには編集が出来ていたので、
今回はテキストの形式が問題とは考えにくいところではあったのですが・・)

ただ、メールやWordからデータを貼り付けることも多いので、そのままリッチテキスト形式に
しておこうかとも思ったのですが、
ためしに新規で別のメールをコピーペーストしてみたところ、
今度はフォーム上での表示の際に改行がまったく無くなってしまい、読みづらくなってしまいました。
(これは、元々のメールがプレーンテキスト形式だったためでしょうか?)

フォームでのテキストボックスの設定では改行等に影響のありそうなプロパティは見当たらなかったのですが、
もしこちら(改行を保ちつつデータを貼り付ける)を解決できる方法がありましたら、お教えいただけるとうれしいです。


元々の質問も併せて、引き続き宜しくお願いいたします。

タイトルRe^2: RTF と TXT
記事No83194
投稿日: 2017/11/22(Wed) 18:04
投稿者mayu
解決済: ON
> これまで、修正ができなくなる不具合が発生したのは、
> ・A4サイズ2ページ以上の文字量となるテキストデータ。
> ・Emailメッセージのコピーデータ。

EUC-JPのLinuxなど、Windows以外の環境で記述された文章ならともかく
プレーンテキストのやり取りで このような現象が出るとは考えにくく
> Wordデータの貼り付けの場合以外は、この方法で上書き保存が出来ています
ということから データ起因ではないかと考えましたが
> もともと、新規データベースを作って同じデータを貼り付けたときには編集が出来ていた
ということですと、オブジェクト要因なのではないでしょうか。

現在運用中のデータベースは
新規データベースと同じOS・Accessバージョンで開発されたのでしょうか。

 ・ 作成時のAccessバージョンが新規データベース作成時のバージョンとは異なる。
 ・ mdb → Accdb に変換した。
 ・ 32bitマシンで作成したものを 64bitマシンで稼働させている
 ・ Officeが 32bit → 64bit に変更となっている

いずれかが該当していれば、不思議ではないですが。

或いは、オブジェクトの一部が破損しているか、です。
その場合は
新規 accdb を作成し、元の accdb から
全てのオブジェクトをインポートしてみるといいでしょう。

多少の破損なら修復され、オブジェクトに蓄積していたゴミも無くなるため
最適化を実施するより容量も小さくなります。

> 今度はフォーム上での表示の際に改行がまったく無くなってしまい、
> (改行を保ちつつデータを貼り付ける)を解決できる方法
私は、記事No:83192 で
> テーブルの書式・フォームのテキストボックス共にリッチテキストに設定
と記載しています。
テーブルのプロパティかフォームのテキストボックスのどちらかが
テキスト形式のままなのではないでしょうか。
( ※ リッチテキストで 改行を入力する場合は Ctrl + Enter )

> 顧客IDで新規対応入力フォームを立ち上げ、対応記録を入力して保存
> 修正する場合は別途修正フォームで編集
入力フォームと修正フォームは 連結なのか、非連結なのか わからないですが
 ・ 入力 と 編集で オブジェクトを分けている理由
 ・ 両オブジェクトの構成差分
 ・ 入力フォームでは再編集可能で編集フォームで編集不可となるケースの有無
 ・ 非連結の場合、どういった手段を用いて編集を確定しているのか
 ・ 編集不可となったメールの本文は、RTF なのか TXT なのか確認してみる
 ・ 編集不可となったデータの文字数をカウントしてみる
といった切り分けや説明が必要かもしれませんね。

タイトルRe^3: RTF と TXT
記事No83195
投稿日: 2017/11/30(Thu) 11:50
投稿者しま
解決済: ON
mayu様

お世話になります。すっかり返信が遅くなってしまい、申し訳ありませんでした。
大変勝手ではありますが、引き続きお付き合いいただけると嬉しいです。


> 現在運用中のデータベースは
> 新規データベースと同じOS・Accessバージョンで開発されたのでしょうか。
>
>  ・ 作成時のAccessバージョンが新規データベース作成時のバージョンとは異なる。
>  ・ mdb → Accdb に変換した。
>  ・ 32bitマシンで作成したものを 64bitマシンで稼働させている
>  ・ Officeが 32bit → 64bit に変更となっている
>
> いずれかが該当していれば、不思議ではないですが。

こちらに関しては、該当しないと思います。
最初に新規データベースを作成したときから、パソコンも変わっておりませんし、バージョンアップ等もしていません。


> 或いは、オブジェクトの一部が破損しているか、です。
> その場合は
> 新規 accdb を作成し、元の accdb から
> 全てのオブジェクトをインポートしてみるといいでしょう。
>
> 多少の破損なら修復され、オブジェクトに蓄積していたゴミも無くなるため
> 最適化を実施するより容量も小さくなります。


こちらも期待して早速実践してみたのですが、不具合の症状は変わりませんでした・・。
また、そこからヒントを得て、編集フォームを新規で作り直してみたのですが、
依然、修正できないデータは一定しており、またそこで不思議な現象が発生しました。

概要は下記のとおりです。

---------------------------
<データ>
【tbl顧客基本データ】と【tbl顧客対応記録】の二つを、「顧客ID」フィールドでリレーションシップを組んでいます。
【qry顧客対応記録】で、上記の二つのテーブルを組み合わせています。

<構造>
【frm顧客基本データ(単票フォーム)】の中に【sub_frm対応一覧(帳票フォーム)】があり、
このサブフォーム内の「詳細」ボタンから、「対応記録ID」で該当する【frm対応記録】を開きます。

【frm顧客対応記録】の中に、「編集」ボタンを設けており、「対応記録ID」で該当レコードを呼び出し【frm対応記録編集】を開きます。
-----------------------------

この【frm対応記録編集】なのですが、これだけを単純に開き、修正をすると、テーブル内のレコードに反映されています。
しかし、上記の手順でいくつかフォームを経て【frm顧客対応記録】からこの編集フォームを開くと
なぜか修正が反映されないようです。

なんとなく、問題の場所が狭まってきたような気もするのですが・・。


> > 顧客IDで新規対応入力フォームを立ち上げ、対応記録を入力して保存
> > 修正する場合は別途修正フォームで編集
> 入力フォームと修正フォームは 連結なのか、非連結なのか わからないですが
>  ・ 入力 と 編集で オブジェクトを分けている理由
>  ・ 両オブジェクトの構成差分
>  ・ 入力フォームでは再編集可能で編集フォームで編集不可となるケースの有無
>  ・ 非連結の場合、どういった手段を用いて編集を確定しているのか
>  ・ 編集不可となったメールの本文は、RTF なのか TXT なのか確認してみる
>  ・ 編集不可となったデータの文字数をカウントしてみる
> といった切り分けや説明が必要かもしれませんね。

入力フォームと修正フォームは直接は連結していません。
入力フォームでレコードを格納し、修正フォームではそれを呼び出すという形です。

入力と編集でオブジェクトを分けているのは、単純に編集したいレコードを呼び出す方法を考えたときに、
該当する記録の表示フォームからワンクリックで行けたらなと思ったからです。

”非連結の場合、どういった手段を用いて編集を確定しているのか”については、
今回の問題の


入力フォームと修正フォームは直接は連結していません。
入力フォームでレコードを格納し、修正フォームではそれを呼び出すという形です。

入力と編集でオブジェクトを分けているのは、単純に編集したいレコードを呼び出す方法を考えたときに、
該当する記録の表示フォームからワンクリックで行けたらなと思ったからです。

”非連結の場合、どういった手段を用いて編集を確定しているのか”については、
今回の問題のヒントになっているような気もするのですが、
基礎的な知識がないまま見よう見まねで作ったもので、
恥ずかしながら、自分でも良く分かっておりません。

一貫して不思議なのが、修正できるレコードと出来ないレコードがあり、
修正できないレコードでも、テーブルやクエリから直接の編集の場合には修正できる、という点です。

大変恐縮ですが、別の可能性など思いつかれればお時間の許す時で結構ですので
引き続きお願いできると助かります。

>テーブルのプロパティかフォームのテキストボックスのどちらかが
>テキスト形式のままなのではないでしょうか。
>( ※ リッチテキストで 改行を入力する場合は Ctrl + Enter )

こちらについても、後回しになってしまっていますが、引き続き検証してみます。

よろしくお願いいたします。

タイトルRe^4: RTF と TXT
記事No83196
投稿日: 2017/11/30(Thu) 13:45
投稿者mayu
解決済: ON
> 一貫して不思議なのが、修正できるレコードと出来ないレコードがあり、
> 修正できないレコードでも、テーブルやクエリから直接の編集の場合には修正できる、という点です。

ここがポイントなのではないでしょうか。

記事No:83192 でもご紹介しましたが
https://support.office.com/ja-jp/article/Access-2010-%E3%81%AE%E4%BB%95%E6%A7%98-1e521481-7f9a-46f7-8ed9-ea9dff1fa854
> メモ型フィールドの文字数
> 65,535 (ユーザー インターフェイスからデータが入力される場合)
> 1 GB (プログラムによってデータが入力される場合に使用できる文字領域)
とあることから
まずは、オブジェクト要因 なのか データ要因 なのかを切り分ける必要があります。

ですので、記事No:83194 では
> ・ 編集不可となったデータの文字数をカウントしてみる
という案を提示したのですが、確認なさってみましたか。

> 入力フォームと修正フォームは直接は連結していません。
> 入力フォームでレコードを格納し、修正フォームではそれを呼び出すという形です。

少し誤解があるようですので、補足で説明を加えます。
連結/非連結 とは フォーム同士の関係ではなく、フォームのレコードソースプロパティに
オブジェクト名 や SQL を指定しているか、いないかの違いになります。
設定していれば 連結、空であれば 非連結 です。

タイトルRe^5: RTF と TXT
記事No83197
投稿日: 2017/11/30(Thu) 15:37
投稿者しま
解決済: ON
mayu様

早速のご返信ありがとうございます。

> ですので、記事No:83194 では
> > ・ 編集不可となったデータの文字数をカウントしてみる
> という案を提示したのですが、確認なさってみたのでしょうか。

こちらについて言及しておらずすみません。
とりあえず、最近修正できなかったWordデータの文字数を確認したところ、2000文字強でした。
念のため、修正できるWordデータを無作為に一つ選んで確認しましたら、そちらは約700文字でした。
また、Eメールのテキストデータもカウントしましたら、1500文字ほどでした。

試しに、Wordで新規に文字を打ち、無作為の文字数ごとに貼り付け⇒修正の実験をしてみたところ、
2200文字 ×
2011文字 ×
2010文字 ○
2000文字 ○
1000文字 ○
という結果になりました。Wordの設定等でデータ量は変わってくるのだとは思いますが、
当方では、2010字→2011字がひとつのラインとなっているようです。

ただ、記事No : 83181 でも触れましたが、新規のデータベース(同じ構造)を作って
レコードソースを【tbl顧客データ】にした編集フォームを仮で作ったところ、
問題なく修正ができたため、データ量ではなく構造上の問題かなと考えておりました。(シロウト考えですが・・・)
とはいえ、上記の実験では明らかにデータ量によってなんらかの影響を受けていますね・・。


> > 入力フォームと修正フォームは直接は連結していません。
> > 入力フォームでレコードを格納し、修正フォームではそれを呼び出すという形です。
>
> 少し誤解があるようですので、補足で説明を加えます。
> 連結/非連結 とは フォーム同士の関係ではなく、フォームのレコードソースプロパティに
> オブジェクト名 や SQL を指定しているか、いないかの違いになります。
> 設定していれば 連結、空であれば 非連結 です。

なるほど、勘違いしておりすみませんでした!
【frm対応記録編集】のレコードソースは【qry顧客対応記録】となっています。ので、連結ですね。
また、新規入力用の【frm顧客対応記録入力】のレコードソースは【tbl顧客対応記録】、
表示用の【frm顧客対応記録】のレコードソースはSQL構文?(SELECT tbl顧客対応記録*・・・)となっています。

>具体的な手段やフォームのプロパティが提示されていませんので、何とも言えませんけど
>直接開くか、他フォームを経由して間接的に開くかだけの違いで
>そのような事象が発生する要因になるとは考えにくいのですが、確実な情報でしょうか。
>他フォーム経由で【frm対応記録編集】を開く際、
> ・ データ入力用
> ・ 追加の許可
> ・ 削除の許可
> ・ 更新の許可
>いずれかのプロパティを変更してはいませんか。

この部分ですが、
・データ入力用:いいえ
・追加の許可:はい
・削除の許可:はい
・更新の許可:はい
となっており、これで問題ないと思うのですが・・。

答えに近づいているのかどうかも分からない状態ですが、何かヒントになれば幸いです。
引き続き、お付き合い願えれば大変嬉しく思います。よろしくお願いします。

タイトル問題点の整理
記事No83200
投稿日: 2017/11/30(Thu) 22:58
投稿者mayu
解決済: ON
> とりあえず、最近修正できなかったWordデータの文字数を確認したところ、2000文字強でした。
> 念のため、修正できるWordデータを無作為に一つ選んで確認しましたら、そちらは約700文字でした。
> また、Eメールのテキストデータもカウントしましたら、1500文字ほどでした。

文字数ごとに貼り付けということですけど
Word のデータは RTF ですから、目視可能な文字列以外のデータも含みます。
文字数は Word ではなく、Access上でカウントしていただけますか。
また、Access上で
どのオブジェクト上で、どのような手法を用いて文字数をカウントしたのか
といった手段も具体的にお書きください。

> 修正フォームで、テキスト自体を書き換えることはできるのですが、
> それを上書き保存してもテーブル内のデータに反映されていません。

文字数が数百・数千にも及ぶデータに対して
テーブルを開いて目視確認という手段は( 通常は )選択しないと思います。
具体的に、どういった方法を用いてテーブルに反映されていないことを確認されたのでしょうか。

> Wordデータの貼り付けの場合以外は、この方法で上書き保存が出来ています
> ・A4サイズ2ページ以上の文字量となるテキストデータ。
> ・Emailメッセージのコピーデータ

Word と Eメール以外のデータなら上書き出来ているということですが
言い換えると、{ RTFのデータを貼り付けた時にだけ }発生する現象ではないのでしょうか。
https://support.microsoft.com/ja-jp/help/882543
文字数が 2010 以上の Word ドキュメントをテキスト形式で保存し、
TXT に変換された長文をフォーム上のテキストボックスに貼り付けた場合、
再編集は可となるのか、不可になるのか、どちらでしょうか。

> 【frm対応記録編集】のレコードソースは【qry顧客対応記録】となっています。ので、連結ですね。
> また、新規入力用の【frm顧客対応記録入力】のレコードソースは【tbl顧客対応記録】、
> 表示用の【frm顧客対応記録】のレコードソースはSQL構文?(SELECT tbl顧客対応記録*・・・)となっています。

新規入力用と編集用のフォームは共に連結フォームではあるが
レコードソースは異なるということですね。
また、frm顧客対応記録 のレコードソースについて 確信がおありでないようですが
このデータベースは、しまさんが全て作られたものでしょうか。
それとも、一部 別の方が作られたものでしょうか。

> この【frm対応記録編集】なのですが、これだけを単純に開き、修正をすると、
> テーブル内のレコードに反映されています。
> しかし、上記の手順でいくつかフォームを経て【frm顧客対応記録】からこの編集フォームを開くと
> なぜか修正が反映されないようです。

いくつかフォームを経て編集フォームを開くと修正は必ず反映されないのか
或いは、一定の条件を満たした場合のみ反映されないのか、どちらでしょうか。
また、複数のフォームを経てのみ、問題が発生する場合においては
フォームを経る手段( マクロやVBAの記述内容 )を提示いただけますか。

タイトルRe: 問題点の整理
記事No83202
投稿日: 2017/12/01(Fri) 09:19
投稿者しま
解決済: ON
mayu様

おはようございます。
ご丁寧にお付き合いくださり、本当に感謝申し上げます。

一つ一つ、検証してまたご連絡させていただきます。
週末に入ることもあり少しお時間をいただくかと思いますが、来週頭にはお返事できるよう努めます。
お待ちいただけると嬉しいです。

取り急ぎ。

タイトルRe: 問題点の整理
記事No83207
投稿日: 2017/12/04(Mon) 11:54
投稿者しま
解決済: ON
mayu様

引き続きお世話になります。

> > とりあえず、最近修正できなかったWordデータの文字数を確認したところ、2000文字強でした。
> > 念のため、修正できるWordデータを無作為に一つ選んで確認しましたら、そちらは約700文字でした。
> > また、Eメールのテキストデータもカウントしましたら、1500文字ほどでした。
>
> 文字数ごとに貼り付けということですけど
> Word のデータは RTF ですから、目視可能な文字列以外のデータも含みます。
> 文字数は Word ではなく、Access上でカウントしていただけますか。
> また、Access上で
> どのオブジェクト上で、どのような手法を用いて文字数をカウントしたのか
> といった手段も具体的にお書きください。

無知ですみません。
再度、今度はACCESS上で、新規クエリ(【tbl顧客基本データ】+【tbl顧客対応記録】)を作成し、
LEN関数で【tbl顧客対応記録】内の対応記録フィールドの文字数をカウントしましたところ、
一番大きなデータで5343字(メール貼り付けレコード)でした。
ちなみに、ずっと検証で使っていたWordデータ貼り付けレコードはWordで2000文字強だったところ、ACCESSでは2743字でした。

mayu様のご質問のおかげで一つ分かったことがあります。
メールやWordのコピペデータに限らず、
入力フォームから手打ちで入力したデータでも、ある一定の文字数を超えると修正が反映されないようです。
文字数を降順で並べたところ、やはり2000文字前後がフォーム上での修正可否のラインのようです。
1800文字は修正ができました。
これまで、手打ちでそこまで大きなデータを入力することが無かったので、気づいておりませんでした。
確認不足で申し訳ありません。

> > 修正フォームで、テキスト自体を書き換えることはできるのですが、
> > それを上書き保存してもテーブル内のデータに反映されていません。
>
> 文字数が数百・数千にも及ぶデータに対して
> テーブルを開いて目視確認という手段は( 通常は )選択しないと思います。
> 具体的に、どういった方法を用いてテーブルに反映されていないことを確認されたのでしょうか。

もし見当違いな答えをしていたらすみません。
確認方法ですが、該当レコードを編集フォームで開き、最初の一文を書き換え(「ああああ」⇒「あいあい」のように)、
保存ボタンで上書き保存をしています。
(保存ボタンはプロパティ⇒クリック時イベント⇒イベントプロシージャで動作を記述しています。)
保存した後に、再度このレコードを表示フォームで開きますが、最初の一文は編集前のままです。
また、レコードの保存してあるテーブルを見ても、最初の一文は変更されていません。
そこで、そのテーブルのレコードをそのまま書き換えてみると、書き換えた内容で保存されています。

こういったことから、上記のような報告をさせてもらいました。

>
> > Wordデータの貼り付けの場合以外は、この方法で上書き保存が出来ています
> > ・A4サイズ2ページ以上の文字量となるテキストデータ。
> > ・Emailメッセージのコピーデータ
>
> Word と Eメール以外のデータなら上書き出来ているということですが
> 言い換えると、{ RTFのデータを貼り付けた時にだけ }発生する現象ではないのでしょうか。
> https://support.microsoft.com/ja-jp/help/882543
> 文字数が 2010 以上の Word ドキュメントをテキスト形式で保存し、
> TXT に変換された長文をフォーム上のテキストボックスに貼り付けた場合、
> 再編集は可となるのか、不可になるのか、どちらでしょうか。

修正できないWordデータをテキストデータ(書式なし)で保存し、.txtとなっていることを確認し、
通常のやり方でフォーム上に新規入力し保存→編集画面で呼び出し修正、を試みましたが、
結果は同じ(修正が反映されない)でした。

やはり、前述したようにコピペか手打ちに限らず、データ量で修正の可否が変わっていることを受けると
テキスト形式かリッチテキスト形式かというのはここでは原因ではないのでしょうか。
(こちらの思い込みでコピペ時のみの問題と捉えておりすみませんでした・・)

> 新規入力用と編集用のフォームは共に連結フォームではあるが
> レコードソースは異なるということですね。
> また、frm顧客対応記録 のレコードソースについて 確信がおありでないようですが
> このデータベースは、しまさんが全て作られたものでしょうか。
> それとも、一部 別の方が作られたものでしょうか。

このデータベースは一から私一人で作成したのですが、
何か実現したいことがある都度、こちらのHPやサンプルDBを参考にしたりコピーしたりしながら
文字通り”見よう見まね”で作ったものですので、SQL構文を記述した経緯については
恥ずかしながらあまり覚えていないのです。

> > この【frm対応記録編集】なのですが、これだけを単純に開き、修正をすると、
> > テーブル内のレコードに反映されています。
> > しかし、上記の手順でいくつかフォームを経て【frm顧客対応記録】からこの編集フォームを開くと
> > なぜか修正が反映されないようです。
>
> いくつかフォームを経て編集フォームを開くと修正は必ず反映されないのか
> 或いは、一定の条件を満たした場合のみ反映されないのか、どちらでしょうか。
> また、複数のフォームを経てのみ、問題が発生する場合においては
> フォームを経る手段( マクロやVBAの記述内容 )を提示いただけますか。

基本的な使用の際は、まず【frm顧客基本情報】を開き、その中にあるサブフォーム【sub_frm顧客対応記録(帳票フォーム)】の詳細ボタンから【frm顧客対応記録(単票フォーム)】を開き、記録を閲覧します。
内容を修正したい時に、このフォーム内にある修正ボタンから【frm対応記録編集】を開き、レコードの修正を行い、保存ボタンで上書きしています。

オブジェクト一覧からそのまま【frm対応記録編集】を開きますと、最新のレコードが表示され、そこから修正した場合には即時にテーブルに修正が反映されます。(文字数に関わらず、これは反映されます)
しかし、上記の流れを経て当該フォームを開き修正をすると、文字数の多いデータのみ、この修正が反映されません。

ちなみに、オブジェクト一覧からそのまま【frm顧客対応記録】を開き、【frm顧客対応記録】を開いた場合で同様の事象が起こりましたので、複数のフォームを経て、というより、この部分だけで問題が生じているのかも?とも思いました。

【frm顧客基本情報(レコードソース=tbl顧客基本データ)】と【sub_frm顧客対応記録(qry顧客対応記録)】はリンク親・子フィールドで、顧客IDで繋がっています。
【sub_frm顧客対応記録】の詳細ボタンはコントロールウィザードを使って、対応記録IDの一致する【frm顧客対応記録(qry顧客対応記録)】を開くようにしてあります。
【frm顧客対応記録(qry顧客対応記録)】の中の修正ボタンも、同様にウィザードを使って対応記録IDの一致する【frm対応記録編集(qry顧客対応記録)】を開きます。

参考になるか分かりませんが、【frm対応記録編集】のレコードソースをtbl顧客対応記録に変えて検証をしてみましたが、この場合も修正は反映されていませんでした。

また、もう一度【frm対応記録編集】を新規で作り直してみたりもしたのですが、やはり【frm顧客対応記録】からこれを開くと同じ自称になります。

毎回長文で申し訳ありません。よろしくお願いいたします。

タイトルRe^2: 問題点の整理
記事No83208
投稿日: 2017/12/04(Mon) 12:07
投稿者しま
解決済: ON
追記です。

> 今度はフォーム上での表示の際に改行がまったく無くなってしまい、
> (改行を保ちつつデータを貼り付ける)を解決できる方法
私は、記事No:83192 で
> テーブルの書式・フォームのテキストボックス共にリッチテキストに設定
と記載しています。
テーブルのプロパティかフォームのテキストボックスのどちらかが
テキスト形式のままなのではないでしょうか。
( ※ リッチテキストで 改行を入力する場合は Ctrl + Enter

以前、リッチテキスト形式を推奨いただき、上記のご指摘をいただいた点も確認しました。
わたしのミスで入力フォームをテキスト形式のままにしていたのが原因でした。
全てのフォームでリッチテキスト形式に変更したところ、表示も問題なくなりました。
ありがとうございました!

また、前ポストにて記載した今回の検証は、リッチテキスト形式に変えてからも行っていますが、
修正が反映されない点は依然変わっておりません。

よろしくお願いいたします。

タイトルVBAによる更新は別セッション
記事No83209
投稿日: 2017/12/04(Mon) 15:12
投稿者mayu
解決済: ON
> 基本的な使用の際は、まず【frm顧客基本情報】を開き、
> その中にあるサブフォーム【sub_frm顧客対応記録(帳票フォーム)】の詳細ボタンから
> 【frm顧客対応記録(単票フォーム)】を開き、記録を閲覧します。
> 内容を修正したい時に、このフォーム内にある修正ボタンから
> 【frm対応記録編集】を開き、レコードの修正を行い、保存ボタンで上書きしています。

各フォームの「 レコードロック 」プロパティが
どういう設定になっているのかわかりませんが

 【 同一レコードソース の 同一レコード を3つのフォームで 同時 に開いている 】

わけですよね。それに加えて

> 文字数を降順で並べたところ、やはり2000文字前後がフォーム上での修正可否のラインのようです。
> 1800文字は修正ができました。

ということですと
> テキスト形式かリッチテキスト形式かというのはここでは原因ではないのでしょうか。
RTF, TXT という形式の問題ではない、でしょう。

Accessデータベースエンジンのページサイズは
確か 4K( 約 4,000 バイト ) だったと記憶しています。
( レコードサイズは 4K 単位で確保されていきます )

1,800文字 は Unicode で 3,600バイト ですから、1ページ( 4K内 )に収まりますけど
2,000文字以上 は 1ページ に収まりきらないので
DBエンジンは、次のページを確保する必要があるのですが 

レコードソースを同一とする複数のフォームで
同一レコードの編集を可とする構成にしているため、
編集時におけるページサイズが確保できなくなったか
セッションの競合が発生しているのではないかと推測します。

で、競合を発生させている{ 最も怪しい行為 }が
> 保存ボタンで上書きしています。
これです。

VBA でテーブルデータの編集を実施すると、一連の動作は
連結フォーム上の手作業による更新とは 別セッションになりますので
セッション競合が発生しても、何も不思議ではないと思います。

セッション競合の意味が全くわからないという場合、

  連結フォーム上での更新が保留になっている状態で
  新たに、別セッション( VBA )で同一データを更新しようとしている
      
と言い換えたら、ご理解いただけるでしょうか。

つまり 記事No:83195 で、しまさんが不審に思われている
> 一貫して不思議なのが、修正できるレコードと出来ないレコードがあり、
> 修正できないレコードでも、テーブルやクエリから直接の編集の場合には修正できる、という点です。
ですが、
この編集方法だと、テーブル/クエリ の GUI によって該当ページがロックされても
( レコードセレクタに鉛筆マークが表示されている状態 )
VBA による別セッションが発生するという状況にならないため、編集が成功するのです。

連結フォーム上でのレコード編集においては
フォームを閉じたり、レコードを移動すると 自動で編集が確定するため
通常、「 保存ボタンなど使う必要が無い 」のですが
このボタンで何をなさっているのでしょうか。

> (保存ボタンはプロパティ⇒クリック時イベント⇒
> イベントプロシージャで動作を記述しています。)
私は、100%に近い割合で、この記述内容に問題があると考えています。
VBAのソースコードを提示いただけますか。
なお、別サイトで参考にした情報があるのでしたら そのURLも載せて下さい。

現時点でアドバイスできるのは以下の2点です。
( 私の推測が正しければ、おそらく以下の行為では直りませんけど )

【 1 】
------------------------------------------------------
「 ファイル 」タブから
  → オプション
   → クライアントの設定
    → 詳細設定
     → レコード レベルでロックして開く

のチェックを外して下さい。

【 2 】
------------------------------------------------------
「 ファイル 」タブから
  → オプション
   → カレント データベース
    → 名前の自動修正オプション
     → 名前の自動修正情報をトラックする

のチェックを外して下さい。

タイトルRe: VBAによる更新は別セッション
記事No83210
投稿日: 2017/12/04(Mon) 16:45
投稿者しま
解決済: ON
mayu様

引き続き、お付き合いいただき本当にありがとうございます。


当たり前ですが、私の考えの及ばないところを指摘いただけて、
これはもう解決できないかと思っていた問題が、ゴールに近づいているようで少し興奮しています。

まず、最初にこちらですが

> 現時点でアドバイスできるのは以下の2点です。
> ( 私の推測が正しければ、おそらく以下の行為では直りませんけど )
>
> 【 1 】
> ------------------------------------------------------
> 「 ファイル 」タブから
>   → オプション
>    → クライアントの設定
>     → 詳細設定
>      → レコード レベルでロックして開く
>
> のチェックを外して下さい。
>
> 【 2 】
> ------------------------------------------------------
> 「 ファイル 」タブから
>   → オプション
>    → カレント データベース
>     → 名前の自動修正オプション
>      → 名前の自動修正情報をトラックする
>
> のチェックを外して下さい。

ご指示いただいた2箇所のチェックを外し、再起動して同じレコードの修正を試みましたが、
ご想像のとおり、動作は変わりませんでした。

次に、保存ボタンについてです。

> 連結フォーム上でのレコード編集においては
> フォームを閉じたり、レコードを移動すると 自動で編集が確定するため
> 通常、「 保存ボタンなど使う必要が無い 」のですが
> このボタンで何をなさっているのでしょうか。

編集フォーム上には、キャンセルボタン(保存せずに閉じる)も設けているのですが、
ACCESSの操作やコンピューターの操作にあまり慣れていない方でも
視覚的に操作ができるように保存ボタンを設けました。

まぎらわしくないように、レコードセレクタや移動ボタンは非表示にし、
フォーム右上の閉じるボタンも無効にしています。

→もしこのボタンの存在が原因となっているようであれば、単純に閉じるボタンを作成し、
ボタンの標題を「保存」にするという案もありでしょうか?

> > (保存ボタンはプロパティ⇒クリック時イベント⇒
> > イベントプロシージャで動作を記述しています。)
> 私は、100%に近い割合で、この記述内容に問題があると考えています。
> VBAのソースコードを提示いただけますか。

編集フォームのVBAを貼り付けます。

----------------------
Option Compare Database
Option Explicit

Dim CkPoint As Boolean
----------------------
Private Sub cmdキャンセル_Click()

If Me.Dirty Then
DoCmd.RunCommand acCmdUndo
End If
DoCmd.Close


End Sub

--------------------------------
Private Sub cmd保存_Click()

MsgBox "データの保存が完了しました。"
DoCmd.Close acForm, "frm顧客対応記録(編集画面)", acSaveYes


End Sub
--------------------------------

> なお、別サイトで参考にした情報があるのでしたら そのURLも載せて下さい。

すみません、色々なサイトを見ながら作成したもので、
どちらの情報を参考にしたか覚えておりません・・。

> 各フォームの「 レコードロック 」プロパティが
> どういう設定になっているのかわかりませんが

各フォームの「レコードロック」プロパティは全て「しない」に設定していました。
というより、単純にいじってなかったのだと思います。
こちらも設定を変更した方が良いでしょうか。

ちなみに、部署内で同時にこのデータベースを開き編集することもあるのですが、
同一レコードの同時編集は避けたいと思っています。

> VBA でテーブルデータの編集を実施すると、一連の動作は
> 連結フォーム上の手作業による更新とは 別セッションになりますので
> セッション競合が発生しても、何も不思議ではないと思います。
>
> セッション競合の意味が全くわからないという場合、
>
>   連結フォーム上での更新が保留になっている状態で
>   新たに、別セッション( VBA )で同一データを更新しようとしている
>       
> と言い換えたら、ご理解いただけるでしょうか。
>
> つまり 記事No:83195 で、しまさんが不審に思われている
> > 一貫して不思議なのが、修正できるレコードと出来ないレコードがあり、
> > 修正できないレコードでも、テーブルやクエリから直接の編集の場合には修正できる、という点です。
> ですが、
> この編集方法だと、テーブル/クエリ の GUI によって該当ページがロックされても
> ( レコードセレクタに鉛筆マークが表示されている状態 )
> VBA による別セッションが発生するという状況にならないため、編集が成功するのです。
>

分かりやすく記述していただき本当にありがとうございます。
なんとなくですが、VBAによる別セッションがレコードの書き換えの邪魔をしている点は理解できました。

試しに、編集フォームにて、フォーム右上の閉じるボタンを有効にしたうえで、
編集し、「×」で閉じて、修正が反映されるかどうか検証してみました。

すると、編集フォームを開く前の閲覧フォームが開いたままになっているため、
「このマシンの他のセッションによってロックされているので、更新できませんでした」となるのですが、
閲覧フォームを無理やり閉じた後に同じ操作をすると、修正は反映されていました!


とはいえ、できるだけ保存ボタンによる操作を残したいと考えているのですが
上記に貼り付けましたVBA内で修正の余地はありますでしょうか。
もしくは、やはり保存ボタンの設置そのものを見直した方が良いでしょうか。

どうぞよろしくお願いいたします。

タイトルRe^2: VBAによる更新は別セッション
記事No83211
投稿日: 2017/12/04(Mon) 19:30
投稿者mayu
解決済: ON
>「このマシンの他のセッションによってロックされているので、更新できませんでした」となるのですが、

編集不可の原因は、セッション競合で間違いないと思います。

不思議なのは、手作業だけではなく
VBAを用いて更新しようとする時でも、このメッセージが出ると思うのですけど。

> →もしこのボタンの存在が原因となっているようであれば、単純に閉じるボタンを作成し、
> ボタンの標題を「保存」にするという案もありでしょうか?

VBAを使わない状況でも、競合ロックが発生しているわけですから
セッションが競合するようなインターフェースの構成を見直さない限り
根本的な解決にならないと思います。

> 【sub_frm対応一覧(帳票フォーム)】
> 「対応記録ID」で該当する【frm対応記録】

まず、上記2フォームの{ レコードセット }プロパティを
スナップショットに変更することから始め、
設定変更しても、競合ロックが発生するようでしたら

frm顧客対応記録 上の 修正ボタンを押した際、
frm対応記録編集 を開くと同時に frm顧客対応記録 は閉じるよう、
コードを修正してみて下さい。

> 編集フォームを開く前の閲覧フォームが開いたままになっているため、
> 「このマシンの他のセッションによってロックされているので、更新できませんでした」となるのですが、

3つ同時に開いている状況から、1つ減らして2つにしてみるとどうなるのか
フォームのプロパティを変更したら、どのような動きになるのか
1つずつ順番に試していくと、原因となっている箇所が特定できるでしょう。

> 各フォームの「レコードロック」プロパティは全て「しない」に設定していました。
> というより、単純にいじってなかったのだと思います。
> こちらも設定を変更した方が良いでしょうか。
> ちなみに、部署内で同時にこのデータベースを開き編集することもあるのですが、
> 同一レコードの同時編集は避けたいと思っています。

https://support.office.com/ja-jp/article/-RecordLocks-%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF-%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3-6ca29bbb-8824-4671-8087-97fe0568019a
をご覧になるといいでしょう。

タイトルRe^3: VBAによる更新は別セッション
記事No83212
投稿日: 2017/12/06(Wed) 11:29
投稿者しま
解決済: ON
引き続きお世話になっております。遅くなりました。

> 不思議なのは、手作業だけではなく
> VBAを用いて更新しようとする時でも、このメッセージが出ると思うのですけど。

なぜでしょう・・ボタンで更新の場合はこのメッセージは出ることはありませんでした。

> > 【sub_frm対応一覧(帳票フォーム)】
> > 「対応記録ID」で該当する【frm対応記録】
>
> まず、上記2フォームの{ レコードセット }プロパティを
> スナップショットに変更することから始め、

該当する2フォームのレコードセットプロパティをスナップショットに変更し、保存したうえで、
問題レコードの修正を試みましたが、動作は変わりませんでした。

> 設定変更しても、競合ロックが発生するようでしたら
>
> frm顧客対応記録 上の 修正ボタンを押した際、
> frm対応記録編集 を開くと同時に frm顧客対応記録 は閉じるよう、
> コードを修正してみて下さい。

修正ボタンはコントロールウィザードで作成し、埋め込みマクロになっていたので、
「新しいアクションの追加」で、閲覧フォーム(frm顧客対応記録)を閉じるようにしました。
保存し、動作確認を行いましたが、閲覧フォームは閉じるのですが、修正は変わらず反映されないままです。

> > 編集フォームを開く前の閲覧フォームが開いたままになっているため、
> > 「このマシンの他のセッションによってロックされているので、更新できませんでした」となるのですが、
>
> 3つ同時に開いている状況から、1つ減らして2つにしてみるとどうなるのか
> フォームのプロパティを変更したら、どのような動きになるのか
> 1つずつ順番に試していくと、原因となっている箇所が特定できるでしょう。

通常の流れで編集フォームまで到達すると、

1.トップ画面【レコードソースなし・ボタンのみ】

2.顧客検索フォーム【frm顧客データ一覧(ソース→qry顧客基本データ(条件抽出))】

3.顧客基本データフォーム【親:frm顧客基本データ(tbl顧客基本データ)+子:frm_sub顧客対応記録一覧(qry顧客対応記録)】

4.閲覧フォーム【frm顧客対応記録(qry顧客対応記録)】

5.編集フォーム【frm顧客対応記録(編集) (qry顧客対応記録)】

と、合計5つのフォームが開いており(すみません、最初の2つについては記事No : 83207 の中で触れておりませんでした)、そのうち3つ(3、4、5)がクエリを経由してtbl顧客対応記録の同一レコードを読みに行っており、さらに4つ(2、3、4、5)がtbl顧客基本データの情報を読みにいっています。
下記の検証をしてみました。

1と5だけ開いた場合→ ○(編集可能)
1、2と5だけ開いた場合→ ○
1、2、3、5を開いた場合→ ×(編集不可)
1、2、3、4、5を開いた場合(通常の流れ)→ ×

つまり、二つ以上のフォームで同一レコードを読みに行くと、すでに競合が発生してしまうということですよね。

今まで上記1〜5の流れで操作をしてきて、文字数さえ超過しなければ快適に記録ができていたので
できれば大幅な構造の作りかえはしたくないなと思っています。
また、5を開く時に自動的に3,4、を閉じるという方法も、編集後のデータをすぐに閲覧したいという面から、できれば避けたいと思っています。
(基礎を理解しないまま作ってしまったので、身から出た錆であることは重々承知しているのですが・・)

最終的には、記録できる文字数に制限を設け、長文の記録の際にはレコードを分ける、という方法も検討したいと思いますが、今の形で他に思いつかれる方法があればアドバイスいただけると本当に嬉しいです。

> > 各フォームの「レコードロック」プロパティは全て「しない」に設定していました。
> > というより、単純にいじってなかったのだと思います。
> > こちらも設定を変更した方が良いでしょうか。
> > ちなみに、部署内で同時にこのデータベースを開き編集することもあるのですが、
> > 同一レコードの同時編集は避けたいと思っています。
>
> https://support.office.com/ja-jp/article/-RecordLocks-%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AD%E3%83%83%E3%82%AF-%E3%83%97%E3%83%AD%E3%83%91%E3%83%86%E3%82%A3-6ca29bbb-8824-4671-8087-97fe0568019a
> をご覧になるといいでしょう。

最後になりましたが、こちらもありがとうございました。リンク先を参考に、レコードロックはとりあえず「編集済みレコード」に設定してみました。

引き続き、どうぞよろしくお願いいたします。

タイトルRe^4: VBAによる更新は別セッション
記事No83213
投稿日: 2017/12/06(Wed) 16:54
投稿者mayu
解決済: ON
> なぜでしょう・・ボタンで更新の場合はこのメッセージは出ることはありませんでした。

まず、私としまさんで{ 根本から認識が違う }のは、提示いただいてるコードの動作です。

> Private Sub cmd保存_Click()
>   MsgBox "データの保存が完了しました。"
>   DoCmd.Close acForm, "frm顧客対応記録(編集画面)", acSaveYes

このコードでは、{ 保存・更新 }といった行為を一切していません。
コード中の acSaveYes を acSaveNo に替えた後に
データを編集してフォームを閉じてみれば判ることですけど、データは常に上書き更新されます。
言い換えると、今までの質疑応答において
> ボタンで更新
というコードやマクロを、私は一度も拝見していないということになります。
( 引用部分のコードはメッセージを出してフォームを閉じているだけ )

したがって、文字数が 2,000 を超える状態で表示された 編集フォーム上のレコードは
【 最初から更新できる状態に無かったのではないか 】というのが私の推測です。

フォームでのデータ編集時には レコードセレクタが「 鉛筆マーク 」になりますが
他セッションによる ロック時のレコードセレクタ は
駐車禁止の標識のような「 slashed o 」というマークになります。 

もし、本当に 編集を開始した後にセッションが競合する のでしたら
長文編集の際に、キーボードから手を離すことにストレスに感じる方は
定期的に Ctrl + S を押してデータを保存しようと試みるでしょうし
> Private Sub cmdキャンセル_Click()
のボタンを使用しない方も相当数いるのではないかと推測されるため
( 使用しても状態が変化しないので、存在価値を見い出せない )
その時点で、何らかのエラーが出ると考えるほうが自然です。

> 今の形で他に思いつかれる方法があればアドバイスいただけると本当に嬉しいです。
> 1、2と5だけ開いた場合→ ○
> 1、2、3、5を開いた場合→ ×(編集不可)

3と5の間に因果関係があるということが、はっきりしていますよね。
現在のオブジェクト構成で、私がアドバイス出来るのは以下のとおりです。

> 子:frm_sub顧客対応記録一覧(qry顧客対応記録)】
> 閲覧フォーム【frm顧客対応記録(qry顧客対応記録)】 

両フォーム共に、レコードソースには
qry顧客対応記録 とは別のクエリを( 新規に作って )指定し、
sub顧客対応記録ソース用の別クエリ、frm顧客対応記録ソース用の別クエリ 共に
対応記録テーブルの「 内容詳細 」フィールドは含まない構成にします。

なお、frm_sub顧客対応記録一覧のレコードソースは
対応記録テーブルから 必要最小限の列を選択したクエリ で十分だと思います。
少なくとも tbl顧客基本データ のフィールドは必要無いでしょう。

VBAコードでは、frm_sub顧客対応記録一覧 から 閲覧フォーム を開く際
閲覧フォームを開くより先に、フォーカスを一旦
親フォームである frm顧客基本データ へ移動( 退避 )させておくといいでしょう。

また、顧客基本データフォーム( サブフォ含む )、閲覧フォーム では
レコードセットプロパティを { スナップショット } にしておき
顧客基本データフォーム( サブフォ含む )、閲覧フォーム、編集フォーム全てで
レコードロックプロパティは { 編集済レコード } に設定します。

最後に、閲覧フォームに表示させる「 内容詳細 」フィールドのデータは
テーブルの値を直接表示するのではなく、DLookup関数を使って
対応記録テーブルから { データを間接的に参照する }ようにします。

これで、編集フォーム 以外は qry顧客対応記録 を使うことが無くなりますから
{ 内容詳細 }フィールドがロックされるリスクを 少しは減らせるでしょう。

タイトルRe^5: VBAによる更新は別セッション
記事No83214
投稿日: 2017/12/07(Thu) 15:11
投稿者しま
解決済: ON
mayu 様

大変お世話になっております。
懇切丁寧にご説明くださり、本当に感謝しています。
結論から申し上げますと、目指していた「長文でも修正が反映される」形に到達することができました。


> > Private Sub cmd保存_Click()
> >   MsgBox "データの保存が完了しました。"
> >   DoCmd.Close acForm, "frm顧客対応記録(編集画面)", acSaveYes
>
> このコードでは、{ 保存・更新 }といった行為を一切していません。
> コード中の acSaveYes を acSaveNo に替えた後に
> データを編集してフォームを閉じてみれば判ることですけど、データは常に上書き更新されます。
> 言い換えると、今までの質疑応答において
> > ボタンで更新
> というコードやマクロを、私は一度も拝見していないということになります。
> ( 引用部分のコードはメッセージを出してフォームを閉じているだけ )

・・お恥ずかしい限りです。
確かに、acSaveNoにしても上書き保存されていました。ご指摘ありがとうございます。

> 3と5の間に因果関係があるということが、はっきりしていますよね。
> 現在のオブジェクト構成で、私がアドバイス出来るのは以下のとおりです。
>
> > 子:frm_sub顧客対応記録一覧(qry顧客対応記録)】
> > 閲覧フォーム【frm顧客対応記録(qry顧客対応記録)】
>
> 両フォーム共に、レコードソースには
> qry顧客対応記録 とは別のクエリを( 新規に作って )指定し、
> sub顧客対応記録ソース用の別クエリ、frm顧客対応記録ソース用の別クエリ 共に
> 対応記録テーブルの「 内容詳細 」フィールドは含まない構成にします。
>
> なお、frm_sub顧客対応記録一覧のレコードソースは
> 対応記録テーブルから 必要最小限の列を選択したクエリ で十分だと思います。
> 少なくとも tbl顧客基本データ のフィールドは必要無いでしょう。
>
> VBAコードでは、frm_sub顧客対応記録一覧 から 閲覧フォーム を開く際
> 閲覧フォームを開くより先に、フォーカスを一旦
> 親フォームである frm顧客基本データ へ移動( 退避 )させておくといいでしょう。
>
> また、顧客基本データフォーム( サブフォ含む )、閲覧フォーム では
> レコードセットプロパティを { スナップショット } にしておき
> 顧客基本データフォーム( サブフォ含む )、閲覧フォーム、編集フォーム全てで
> レコードロックプロパティは { 編集済レコード } に設定します。
>
> 最後に、閲覧フォームに表示させる「 内容詳細 」フィールドのデータは
> テーブルの値を直接表示するのではなく、DLookup関数を使って
> 対応記録テーブルから { データを間接的に参照する }ようにします。
>
> これで、編集フォーム 以外は qry顧客対応記録 を使うことが無くなりますから
> { 内容詳細 }フィールドがロックされるリスクを 少しは減らせるでしょう。

同じレコードを直接読みに行くのではなく、DLookup関数を使って表示するという方法、目からうろこでした。
早速お教えいただいたように、[内容詳細]フィールドを含まない別クエリを作成し、
[内容詳細]フィールドはDlookup関数で表示するという方法にしたところ、
見事、セッションの競合なく、通常の流れでレコードを編集することができました。

ご指示いただいた操作の意図を完全に理解できたわけではないですが、
今回色々とお教えいただいたことで、本当に勉強になることがたくさんありました。
貴重なお時間を割いてご回答くださったこと、改めて御礼申し上げます。

また質問させていただくことがあるかと思いますが、ご縁がありましたらまたどうぞよろしくお願いいたします。

- 以下のフォームから自分の投稿記事を修正・削除することができます -
処理 記事No パスワード

ページの先頭へ 前ページへ戻る