UPDATE T_出力, T_置換用テーブル
SET T_出力.住所1 = Replace(Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],[T_置換用テーブル].[置換後])
WHERE InStr(1,Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],0)>0;
UPDATE T_出力, T_置換用テーブル
SET T_出力.住所1 = Replace(Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],[T_置換用テーブル].[置換後])
WHERE InStr(1,Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],0)>0;
UPDATE T_出力, T_置換用テーブル SET T_出力.住所1 = Replace(Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],[T_置換用テーブル].[置換後])
WHERE (((T_出力.住所1) Like "*" & [T_置換用テーブル].[置換前] & "*"));
要するにこういう事？
りんごさん 財務の振替の様なもので伝票に記入するイメージで直感的にそれに沿った処理フォームにしています。実際は
品目A 金額A 品目B・金額B
あ 1000 繰越 1000
繰越 500 い 500
で金額ＡとＢの合計値は合致させる必要があります。（繰越入力フォーム基のクエリでこうなる様にしてます）
繰越時はＡ・Ｂどちらかになるかは決まってますが日々の処理ではどちらかになるかはランダムなのです。
これも説明不足でした（すみません）。
>●処理ｲﾒｰｼﾞ（ｻﾌﾞ）
品目A 金額A 品目B・金額B
あ 1000
い 500
但し品目のｸﾞﾙｰﾌﾟにより品目A・金額Aに入るか品目B・金額Bに入るかの切り分けがあります
下記のようにしない理由は？
●処理ｲﾒｰｼﾞ（ｻﾌﾞ）
hatenaさん情報不足で色々すみません。非連結の認識は勘違いしてました。対象のﾌｫｰﾑに直接関係ないｲﾒｰｼﾞでとらえてました。今回の関連するﾃｰﾌﾞﾙ構成としては下記になってます。
①処理ﾒｲﾝ：ﾒｲﾝID、日付、伝票番号、その他項目 ②処理ｻﾌﾞ：ｻﾌﾞID、品目A、品目B、金額A、金額B、ﾒｲﾝID、その他の項目 *品目と金額入力欄が各2ヶ所あり ③品目一覧：品目ID、品目名、繰越金額、ｸﾞﾙｰﾌﾟID ④ｸﾞﾙｰﾌﾟ一覧：ｸﾞﾙｰﾌﾟID、ｸﾞﾙｰﾌﾟ名
社内用財務関係のﾌｧｲﾙです（作成途中）。
特定の品目に繰越金額を入力して（半年毎）、それを処理ﾒｲﾝ、ｻﾌﾞに追加したいのです（日付設定は任意）。但し品目のｸﾞﾙｰﾌﾟにより品目A・金額Aに入るか品目B・金額Bに入るかの切り分けがあります（繰越時）。
③の品目一覧ﾃｰﾌﾞﾙを基に特定の項目に対する繰越金額を入力できるﾌｸｴﾘを作成しました。入力したら品目A・金額A、Bに切り分ける為にIIFで処理してます。入力し易い様にこのｸｴﾘを基にﾘｽﾄ型ﾌｫｰﾑを作成し、処理ﾒｲﾝ、ｻﾌﾞに追加できるｺﾏﾝﾄﾞﾎﾞﾀﾝを用意したいのです。
●繰越入力ｲﾒｰｼﾞ
品目 繰越 IIFにて切り分け ★ﾌｫｰﾑには任意の日付欄と伝票番号（共に非連結）
あ 1000 ⇒ 品目A・金額A
い 500 ⇒ 品目B・金額B
●処理ｲﾒｰｼﾞ（ﾒｲﾝ）
日付 伝票番号
3/31 0000
●処理ｲﾒｰｼﾞ（ｻﾌﾞ）
品目A 金額A 品目B・金額B
あ 1000
い 500
１ﾚｺｰﾄﾞづつ追加は教えて頂いたＤＡＯｺｰﾄﾞで出来ましたのでそれに繰り返し処理が出来たらいいかなと思ってます。
でもそれはどうやってしたらいいか分からなくて。
お手数かけます。
それぞれのテーブル名、フィールド構成、を提示して、
それぞれのデータ例を提示して、
どのような結果が欲しいのか説明してもらえますか。
非連結という言葉の意味を誤解しているようですね。
フォームがテーブルと連結してたら非連結とはいいません。
VBAでするならForループでレコード件数分繰り返せはいいでしょう。
ただ、テーブルがあるのなら追加クエリの方が楽です。
どのような意味で「非連結」という言葉を使ったのでしょうか。
hatenaさん すみません40件程のレコードは非連結というか、あるテーブルに保存されたものです。そのテーブルを加工したクエリがありそれを基に作成したリスト形式のフォームがあります。そのフォームにはサブフォームはありません。金額等の数字だけを入力してまして(項目は固定)それを別テーブルに追加する形です。追加先は日々の処理用でメインが日付や他の項目、サブに必要な項目や金額等が入ります。そのリスト型フォーム上のデータをコマンドボタンで追加したいのです。
式1: InStr(1,Nz([T_出力].[住所1],""),[T_置換用テーブル].[置換前],0)というような演算フィールドは更新できませんからね。
プロシージャを抜ければ、自動で廃棄してくれますので、なくても問題ないです。（あっても問題はないですが。）
プロシージャが長くて、途中で使用済みになったというようなときに、使用済みということを明確にするために、
Set rs = Nothing とするということはありえます。
40レコード程あるとのことですが、非連結フォームなんですよね。
40レコード分の非連結コントロールがあるということですか。
それとも一時テーブルをレコードソースとするサブフォームが埋め込まれているとか。
HatenaさんのSQLビューをコピーしてデザインビューを確認したところ、住所1とInstrの2つに分かれました。1つのフィールドに書こうとしていたから上手くいかなかったのですね。
デザインビュー見ました。
更新するフィールドと抽出条件を設定するフィールドは別にしないと。
上記の回答で新規作成したクエリをデザインビューにして違いを確認してください。
クエリを新規作成して、SQLビューにして、下記のSQLを貼り付けて実行するとどうなりますか。
見にくいかもしれませんが、スクショでのデザインビューです。
hatenaさんへ 追加クエリではなく教えて頂いたＤＡＯでしました。追加は出来たのですが、サブには1レコードづつなのですね？ 40レコード程あるのですが、（メイン１つに対して）一括では出来ないのでしょうか？ （知識不足ですみません）
あとついでにお聞きするのですが rs.Close の後は Set rs = Nothing と記述した方がいいのでしょうか？
SQLビューを開こうとしましたが、'InStr(1,[T_出力].[住所1],[T_置換用テーブル].[置換前],0)'が見つかりません、パラメータや別名が正しいこと、、、を確認してくださいというエラーが出ます。
このエラーが出ているクエリのSQLを提示してください。
エラーの出ないSQLを提示されても意味ないですよね。
一応、下記のSQLを実行してみましたが、エラーなく実行できました。
すみません、現状のSQLとは、Instrに書き換えた方（エラーが出ている方）のことでしょうか？
SQLを見る限りは問題なさそうですね。
簡単なサンプルを作成して確認してみましたが、問題なく実行できました。
クエリを新規作成して、SQLビューに提示のSQLをコピーして貼り付けて実行したらどうなりますか。
下記提示致します。
住所1のみのSQLです。
ありがとうございます。
2台のＰＣでテストしましたが、どちらも発生しました。
よってaccessのバクかと思われます。（office2002ではこのような現象はなかった）
ご回答ありがとうございます！
無事に合計値出すことができました。
テキストボックスとラベルについて性質を理解していないので勉強してみようと思います。
ありがとうございました。
[T_置換用テーブル].[置換前]のテーブル名、フィールド名に間違いはないですか。間違いないなら、現状のクエリのSQLを提示してください。
ご質問の文章を拝見すると、「規定の文字数」の規定の理由が明確に記載されてなかったので、回答が迷走している感じがします。
最初に「レポートは最大サイズが決まっていますので、どこまでもテキストボックスを広げるわけにはいきません。」という記載があれば、その後の回答がスムーズになったかと思います。
※そういう意味で「何か特別な理由があるならば提示したほうが回答がつき易いですよ？」と記載されているのかと思います。
使用される環境によって、出力帳票の仕様は様々かと思いますので、同しようもないときもありますね。大きな会社ですと、レイアウトを一箇所変えるのも申告書が必要だったり、工場側のすべてのプリンターで正常に表示されるか確認が必要になることもあるので、結構厄介なケースもあります。
ただ規定の理由が不明瞭な場合、修正コストを考えると「ちょっとテキストボックスを広げるだけ」のほうが圧倒的に簡単ですぐに修正できます。
なので、自分の望む方向の回答が欲しい場合は、なるべくすべての条件を記載されるのが良いかなと思います。
>> 7
ExcelやWordに例えるとわかります。
文字列が途中で途切れたらセルの幅を広げたり、最大文字列に合わせて列の幅を広げたり、しませんか？
印刷用紙に収まらないならば、レイアウトが崩れるならば、規定の文字数を最初からオーバーしないように入力項目・内容から再検討しませんか？
データベースのレコードが文字数調整で更新・保存される事は普通ではありません。最初からそうならないように設計からやり直さないの？
うーん、納得いかなければ、hatenaさんに意見を求めてみたらどうですか？
テキストボックス幅を広げて対応する理由をご教示下さい。
正しい抽出条件はどのように記述すればよろしいでしょうか。
新規作成でも同様の現象が発生する場合、バグかAccessそのものがうまく動作していない場合もあります。
通常は「いきなり強制終了する」などの現象ですが・・・。
一度Accessをインストールし直すか、または修復してみてはどうでしょうか。
あればアップデーターをあてるのもいいかもしれません。
hatena様
ありがとうございます。
改善いたしました。
ありがとうございます。
新規にデータベースを作って、コンボボックスを配置したらフォームフィルタでパラメータクエリのようになりませんでした。しかし、そのフィールドの配置を中央揃えにしたら同様の問題が起きました。
よって、現在は初期の配置で使用しております。
原因はわかったものの、完全な解決とは至っておりません。
""をとってみましたが、見つかりません、パラメータや別名を確認してくださいというエラーが出ました。
式1: InStr(1,[T_出力].[住所1],"[T_置換用テーブル].[置換前]",0)"で囲んだらそれは文字列です。つまり「[T_置換用テーブル].[置換前]」という文字列と比較していることになりますね。試しに住所1だけにしてみたのですが、
式1: InStr(1,[T_出力].[住所1],"[T_置換用テーブル].[置換前]",0)
抽出条件：＞0にしてみたのですが、１件も抽出されませんでした。
どのように書けばよいのでしょうか？
正に実現したい機能でした。教えてくださりありがとうございました。😄
テキストボックスを広げて対応するのが普通なのですか？
レコードも文字長に合わせてテキストボックスを広げるといった方法はあまり聞きません。
レポートは最大サイズが決まっていますので、どこまでもテキストボックスを広げるわけにはいきません。
そして全ページのテキストボックスではみ出していないか調べる必要がありますし、レイアウト的にも不格好になります。
何か特別な理由があるならば、提示したほうが回答がつき易いですよ？
連結テキストボックスを更新しただけでは、レコードソースのテーブルに反映されません。
レコード保存を実行する必要があります。
レコード移動で実行されます。
レコード保存コマンドを実行すればレコード移動しなくても保存されます。
しません。
新しいフォームを新規作成して再現して下さい。まず、レコードソースを設定しただけで、エラーが起きるのか否か？次にオブジェクトを配置してコードを設定すると、エラーが起きるのか否か？