SELECT kog_入力テーブル・Mナンバー、 X0B 人カテーブル・出力順 K0g 入力テーブル・得意先名。kog 入力テーブル．納品日。 K0g 入力テーブル・ドライ・チルド kog スカテーブル・市良。 K0g 人カテーブル・ベンダー・kog_スカテーブル．ベンダー名 from kog_入力テーブル MHE （（Tkog_入力テーブル・納品日）=［Forms］！［f_新規入力］！［nymd］）） ORDER BY kog_人カテーブル．Mナンバー・kog_入力テーブル・出力順。 kog_入力テーブル．ベンダー：
hirotonさん、hatenaさん 詳しい説明ありがとうございました。
リンク先の質問でも回答がありますし、今回もhatenaさんが回答していますが、 通常、32bit版ACCESSで作成したものが64bit版ACCESS環境で開けないのは、mde、accde形式のファイルです
ACCESSの基礎知識になりますが、ACCESSは2007から標準のファイル形式（の拡張子）がaccdbに変わりました。それ以前の標準のファイル形式（の拡張子）がmdbです
使用が推奨される Access ファイル形式
mdbやaccdbの形式であれば、それを64bit環境で開けるか？というのは基本的に問題になりません（正常に動作するか？は別問題です） 「mdb→accdbに変換」すべきかどうかは、上記リンク先を参考に決定してください
これにたいして、mde、accdeの拡張子を持つファイルは、（それを表す名称は不明ですが）コンパイル済みのACCESSデータベースファイルになります 32bitACCESSでコンパイルを実行すれば、32bit環境で動作するデータベース、64bitACCESSでコンパイルを実行すれば、64bit環境で動作するデータベースになる（互換性はない）ということなのでしょう。これも、mde、accdeどちらの拡張子で保存するか？ということ自体は無関係なので、ファイル形式によって制限のある機能を考慮した上で決定する必要があります
（現状、mdb,mdeファイルが即座に排除されるという状況でもなさそうなので、特別新しい形式に保存しなおす必要はないというのが持論です）
mdb→Accdbに変換（32bitのAccess）
の部分は64bitのAccessでも可能と思います。
昔のMDBファイル(32bit)を探してきて、実際に試してみましたが、変換できました。
mdb→Accdbに変換（32bitのAccess） その後、AccdbをAccdeに変換する（64bitのAccess） 上記で理論的には動作可能ということでしょうか？ とりあえず32bitのAccessを入手して、変換してみます。 情報ありがとうございます。
私自身はruntimeは使いませんので、あくまでWEBで調べた情報と、エラーメッセージからの判断ですが、mde あるいは、Accde を作成した同じbit環境でないと動作しないということだと思います。
mdbがあり、その内容がAccdeと同じということなら、mdbをAccdbに変換してから、64ビット環境でAccdeに変換すればいいでしょう。
一番最初に作成されたのは「.mdb」のようです。 「mdb」→「accdb」または「mde」変換では問題は解決しないですかね？
そうなりますね。 もし、先方にAccdeにする前のAccdbファイルがあるなら、それを送ってもらって、 こちらでaccdeに変換すれば、 64bitで動作するようにできます。 なければ、諦めるしかないでしょう。
情報ありがとうございます。先方は以前のシステム管理者で現在はいないかたのようです。 現在は私がaccessの編集などをしております。 結論はOffice32bitをインストールを行うしか動作環境は作れないということで間違いないでしょうか？
runtimeは作成したときのビット数と同じでないと動作しないという仕様のようです。 https://zawazawa.jp/ms-access/topic/628 でもhirotonさんがリンクを紹介してますね。
ACCDEファイルが32Bit版と64Bit版で共有できない : Access
Office 32bit環境を用意するか、先方に64bitで作成しなおしてもらうことになるかと。
質問のリンク先 論理削除はアンチパターンなのか？ #MySQL - Qiita で提示されているデメリットについて今回の案件で検討してみます。
パフォーマンスへの影響 現在レコード数が約5万件、月2～300件程度の追加、削除(キャンセル)件数3%程度
このぐらいのデータ件数なら、削除フラグフィールドにイデックスを設定しておけば、ほとんど影響ないとかんがえていいと思います。
クエリの複雑化 Accessではクエリはテーブルと同等に扱えます。 上記の回答でしたように、論理削除レコードを除いたクエリを作成しておいて、それを使えば、現象のクエリやフォーム、レポートの修正する必要はありません。 クエリも複雑化しません。
ユニーク制約に工夫が必要 リンク先ではusersテーブルのメールアドレスにユニーク制約(Accessでは「重複なしのインデックス」)を設定する場合を例に挙げてますが、おそらく今回の注文テーブルではそのようなフィールドはないのではないかと。 あったとしても、私の回答の方法では削除日時をフラグフィールドにしているので、複数フィールドインデックスでユニーク制約の設定は可能です。
ということで、今回の要件なら大きなデメリットはないかと思います。
会社のパソコンからは、他サイトに書き込み出来ない為、スマホの画像をコピーして貼り付けてみます。当方は、デスクワークは、殆どしていません。ですのでお時間を頂く事になります。宜しくお願い致します。
SQLはSQLビューで全選択してコピーして、貼り付けてください。
貼り付ける場合は、Markdown記法のコードブロックにしてください。 やり方は下記で説明していますので参照してください。
Microsoft Access 掲示板 の使い方 Microsoft Access 掲示板 - zawazawa
あと、レポートのデザインビューのスクリーンショットを「画像アップロード」してください。
ご返答ありがとうございます。クエリのSQLは、SQLビューをスマホで写真撮った物をアップしても良いですか？
キャンセルになった注文をデータベース上で後日確認したり、復活させることはまずありません。
「まずありません」ということは「絶対ない」ではない「わずかであるがありうる可能性がある」ということですよね。 Accessデータベースはファイルサイズ2GBの制限がありますが、それに達する可能性がないのなら、私なら削除せずに「削除フラグ」を立てておくという方法をとりますね。 インデックスを適切に設定されているなら、パフォーマンスにほとんど影響はないと思いますので。
OSに実装されている「ごみ箱」の機能と同等のもの実装するということをしたことがあります。下記でサンプルを紹介していますのでご参考に。
上記のサンプルでは削除日時フィールドを追加して、それがNullのレコードは生きているレコードと、日時が入力されいいるレコードは削除レコードとしています。 こうしておけば、例えば削除後X年経過したら自動的にテーブルから削除するとか、削除してもいいか確認するとか、、、運用に合わせてお好みに設計できます。
レポートのレコードソースのクエリのSQLを提示してもらえますか。
あと、レポート上のSum関数が設定してあるコントロールのコントロールソースに設定してある式、そのコントロールが設定してあるセクション名、レポートのグループ化/集計の設定も提示してもらえますか。
同等品商品コード1〜5いずれかに商品コードが対応した場合に
商品マスタの商品コード999(メインフォーム)と見積の商品コード999(サブフォーム)を親リンク子リンクすれば、>> 7に近い形になると思いますが、それじゃダメかしら？もしダメならば、どうしたいのかを簡易図(例、スクショ)と文章で説明していただけますか？
ご回答有難う御座います。1の例で行くと選択クエリに合計数を求めているフィールドが2つあり、その両方が空欄の時が総合計が空欄になります。両方とも空欄になる場合どういう風に抽出条件を書けば良いですか？is nullでも非表示できますが、 フィールドの構成を変えない場合の記述の仕方がわかりません。ご教授頂けますと幸いです。
「既存のデータベースであり、キャンセルのフラグがある」なら、キャンセルを抽出条件に使います。すでに運用中であり、仕様を完全に把握しているのでなければ、データの削除に対する影響がわかりません
「既存のデータベースであり、キャンセルのフラグがない」なら、集計に含まないとする条件をそれぞれ追加するしかないでしょう
「既存のデータベースであり、キャンセルを削除する」を考えた場合、今後の運用に問題はないでしょうか？それを正しく削除できますか？誰が、いつ、できますか？
hirotonの場合、設計段階として、Nullを数えるような仕組みを極力排除します。仕組みとしては、「現物票出力日」「出庫日」「梱包明細出力日」の他に「状態」フィールドを設け、「-1;キャンセル;0;現物票未出力;1;未梱包;2;未出庫;3;出庫済み」とします。明確に目的のものを集計するのでミスが起こりません キャンセルについては、「梱包まで済んでキャンセルになった」のようなそれをどうするんだ？という場合もあると思います。要求に合わせて「受注状態（キャンセル・受注・納品済み）」「作業行程（伝票未発行、未梱包、未出庫、出庫済み）」のように、複数フィールドで管理する場合もあります
-1;キャンセル;0;現物票未出力;1;未梱包;2;未出庫;3;出庫済み
-1からの連番にしてしまっているので設計段階で工程をしっかり把握しておく必要があることには注意が必要です。「状態マスタ」テーブルを作成して、数値に意味を持たせないのが正しい正規化ですが、末端の情報にそこまで神経質になって後から良かったと感じたことはそれほどないです
当たり前ですが、削除すべきデータは削除します（ミス登録とか） 「キャンセル」というアクションは「存在しなかったもの」として扱っていいモノでしょうか？そうであるならば、「キャンセル」というアクションが起きたときにデータを削除するようにすればいいです 「とりあえず削除フラグ」というやり方は削除フラグが問題の原因ではなく、「とりあえず」という妥協する姿勢が問題になるのです
現在のレコード数が約5万件、うち出荷済み扱いになっていないのが約1500件
およそ3%が問題のデータということですが、パフォーマンスが問題になった場合、不要分のデータが存在しなかったとするならば、問題が発生するまでの期間の3%の期間だけ延命できることになります パフォーマンスが問題になるならば、もっと根本的な解決が必要です
りんご様 回答ありがとうございます。 ご指摘のとおり同等品商品コード1〜5いずれかに商品コードが対応した場合にサブフォームに表示されるようにしたいと考えております。 お手数ですがよろしくお願いいたします。
もし、レポートを弄れるとしたらどうすれば良いでしょうか？
下記の２つの方法が考えられます。
>> 6 SQLのようなコードではなく、商品コードの事だったんですね。理解不足でしたね、すみません。 >> 5 例、見積テーブル
商品マスタの商品コード:999
見積の同等品商品コード1〜4:001,002,003,004,005
やりたい事は、見積テーブルの商品コードを開いたら、対応する同等品商品コード1〜5がサブフォームに表示される、みたいな感じかしら？
りんご様 ご指導ありがとうございます。 hatena様がおっしゃる通り初心者であまりわかっていません。これから少しずつではありますが勉強させていただきます。 またご助言をいただければ幸いです。
hatena様 回答が遅くなり申し訳ありません。 また、説明不足もあり大変失礼いたしました。 今回の件を再度ご説明させていただきます。 今回の件は、商品の見積もりのデータベース化を目的としています。メインフォームにて商品を表示させたときにサブフォームに同一商品見積一覧、もう一つのサブフォームに同等品見積一覧を表示させようとしています。 テーブルは商品マスタと見積の2つになります。 商品マスタのフィールドには、日付（日付/時刻型）、品目（短いテキスト）、メーカー（短いテキスト）、商品名（短いテキスト）、商品コード（短いテキスト）があります。 見積のフィールドには、日付（日付/時刻型）、商品コード（短いテキスト）、同等品商品コード１（短いテキスト）、同等品商品コード２（短いテキスト）、同等品商品コード３（短いテキスト）、同等品商品コード４（短いテキスト）、同等品商品コード５（短いテキスト）、価格（通貨型）があります。 なお、商品マスタの商品コードと見積の商品コードをリレーションシップしてあります。 メインフォームはフォームデザインにて商品マスタのフィールドと商品見積一覧のサブフォーム、同等品見積一覧のサブフォームを表示させてあります。 メインフォームのレコードソースはテーブルの商品マスタになります。 商品見積一覧のサブフォームのソースオブジェクトはテーブルの見積でリンク親フィールドならびにリンク子フィールドは商品コードにしてあります。 同等品見積一覧のサブフォームのソースオブジェクトはテーブルの見積でリンク親フィールドは商品コード;商品コード;商品コード;商品コード;商品コード、リンク子フィールドには、同等品商品コード１;同等品商品コード２;同等品商品コード３;同等品商品コード４;同等品商品コード５にしてありましたが同等品は表示されませんでした。 拙い説明ではありますが以上になります。また、不足している場合があるようでしたらご面倒をおかけしますがご指摘をよろしくお願いいたします。
hatenaさんの仰る通りの状況です。もし、レポートを弄れるとしたらどうすれば良いでしょうか？
SUM関数の集計がレポートのレコードソースのクエリにあるのなら望みはありますが、 レポート内のテキストボックスで=Sum([フィールド名])などとしている場合は、 レポートを一切触る権利が一切ないなら無理ですね。
DoCmd.OpenReport の引数のフィルターに合計が文字列0を指定すれば出来るのか試してみます。ありがとうございました。
レポートを一切触る権利が当方には有りません。当方が、作ったレポートでは無い為でかつ長年そのフォーマットで運用してきた為です。空欄が出るのは、お客様が休業日で注文が無かった場合発生し、レポートにある総数量を求めるSUM関数が0の時空欄になります。ですので、受注次第で総数量が0の時は変動し、無駄紙となります。帳票の構造は、テーブルに注文のあったメーカーの注文数をフォームを通してテーブルに入力していく構造です。総数量の合計0を取得できればよいのですが。毎日の印刷枚数は、200前後で平日は、無駄紙が余り発生しないのですが、連休が絡むと細々と発生します。
現状、手作業で無駄紙を破棄しているのなら、 手作業にはなりますが、プレビューで無駄紙のページ数を確認して、印刷するときに無駄紙を除いたページを指定して印刷すれば、用紙の無駄遣いは抑制できますね。
レポートにいっさい手を付けることができないという状況でしょうか。 私が提案したレポートのイベントを利用することも含めて。
そもそもなぜ、空欄のページで出るのか、その仕組みが不明です。データがないものは出力されないのが通常ですので、なんらかの特別の方法をつかっていると思うのですが、どのような方法を使っているのか提示できませんか。
レポートのレコードソースのクエリにも手を付けられないのでしょうか。 抽出条件を設定することで、空欄の出力を抑制できるのなら、 DoCmd.OpenReport の引数にフィルターを設定できるので、それを利用できるかもしれません。
あるいは、空欄になるページが事前に取得できるなら、DoCmd.PrintOut で印刷するページ数を指定できるので、空欄以外のページを印刷するようにはできます。
どちらにしても、提供されている情報からは、これ以上の具体的な提案は難しいですね。
ご返答誠に有難う御座います。無駄紙は、いつも廃棄しており、経費節減の為何とかならないかと考えていました。総数量の座標が空欄の時をvbaやCOM等で取得しvbaで具現化できればと考えていました。vbaは、accessから独立しておりクエリ等を弄るのでは無く違った方法で出来るのではと考えておりましたが、もし可能であっても相当難しそうですね。
hirotonさんの回答でほとんど網羅してますが、少し補足を。
ご返答有難う御座います。テキストファイルにvbaのコードを貼り付けて、標準モジュールに貼り付けて実行を考えていましたが、特殊なイベントをハンドルする必要がある場合は、許可を貰えば可能です。
標準モジュールから、プレビューされたものを制御することはできないでしょう。 イベントをハンドルすることが可能なら、レポートの「フォーマット時」イベントで Cancel = True とすれば、そのセクションの出力をキャンセルできますので、それを使うことができるかもしれません。
要件が不明瞭ですね
このレポートは、変更を加える事が出来ない為
変更が難しいのは、レポートを構成する要素でテーブル、クエリ、レポートは、難しいです。 因みに、この様な無駄紙を発生させたくない場合、一般的には、どの様な手法を取るのでしょうか？
そのレポートは、お客様の要望の構成になっており、いじる事が出来ません。
何がよくて何がダメなのかわかりません
因みに、この様な無駄紙を発生させたくない場合、一般的には、どの様な手法を取るのでしょうか？
お客様の要望で無駄紙なのでなくしてもいい・なくしたいなのでしょうか？ すべて空白でも必要な書類というものもあるので、ここまでの話では、手を入れてはダメなのでは？と思います
普通、出力不要なモノはレコード単位で出力を制限します（データベースなので） これを制御するならクエリです（または、そもそも数量のないものはテーブルに記録されないので出力されません）
レポートの書式を一定に保つならば
余白に応じて行数指定無く用紙の最後まで罫線を出力する（hatena chipsさん）
書式を一定に保つ手法はアプローチがいくつかあるので使いやすいものを検討すると良いです これは「レポート」を変更（改修）することになります
総数量欄が空欄のページの取得が出来るだけでも
上述した通り、そもそも存在しないものが出力されている状態が疑問です。何かそうしなければならない理由とそれを実現するために構築したレポートの仕様があるはずです 特殊な事情があるのであれば状況や仕様の説明がなければ解決案も出せません
各ページに出力される項目が固定ならば、事前にその項目のグループで集計を行って、出力のあるグループだけをクエリで抽出すれば実現できると思います
ACCESSはデータベース管理ソフトです。データを効率的に管理、運用するために、テーブル、クエリ、フォーム、レポートを相互に連携させながら適切なデータ構造の構築、操作の制限、処理の最適化を行っていきます。これらを「変更できない」では何もできません。「ACCESS」がどのようなアプリケーションなのか、正しい理解と、お客様とのすり合わせを行って、何をしたいのか、何故それがダメなのか、本当にそれが望んでいることなのか見極めてください
あー確かに。すごくわかるんですけど、経験不足などでこの回答は難しいです。 hatenaさん、hirotonさん、skさん・・・だったかな、もっと詳しい回答者の方々、お願い♪
ご返答有難う御座います。レポートは、空欄ありきになっています。そのレポートは、お客様の要望の構成になっており、いじる事が出来ません。総数量欄が空欄のページの取得が出来るだけでも助かるのですが、難しいでしょうか？
レポートが元々空欄マスありきになっていて、問題が発生している場合、そうならないように新しいレポートを作成するのはどうでしょう？ レポートのレコードソースに元々不要なものが含まれていて、問題が発生している場合、レコードソースを遡って、フォーム・クエリ・テーブルを改善するかな。
ご返答有難う御座います。テキストファイルにvbaのコードを貼り付けて、標準モジュールに貼り付けて実行を考えていましたが、特殊なイベントをハンドルする必要がある場合は、許可を貰えば可能です。変更が難しいのは、レポートを構成する要素でテーブル、クエリ、レポートは、難しいです。 因みに、この様な無駄紙を発生させたくない場合、一般的には、どの様な手法を取るのでしょうか？
印刷プレビューを呼び出す前後で直接外すのは難しいでしょう。
このレポートは、変更を加える事が出来ない為、可能であればvbaで有れば幸いです。宜しくお願い致します
変更を加える事が出来ないようになっているのであれば、例え可能であったとしてもレポートに変更を加えるVBAは控えたほうがよろしいのではないかしら？
不明な点は推測で補って、下記のようだと仮定すると、
サブフォームのレコードソースは「コードをいれるフィールドが5つあるテーブル」 テーブル名 Tbl1 5つのフィールド名 Code1, Code2, Code3, Code4, Code5
メインフォームにコードを入力するテキストボックスが一つある。 メインフォーム名 MF1 テキストボックス名 txt1
このテキストボックスのコードがCode1～Code5のいずれかと一致しするレコードを抽出する。
だとしたら、 Tbl1からクエリを作成して、デザインビューで下記のように設定
今回の条件はOR条件ですので、抽出条件は上記のように行をかえて設定します。 ちなみに、親リンクと子リンクの設定ではAND条件になりますので、今回の要件では使えません。
このクエリをサブフォームのレコードソースにする。
txtコードにコードを入力したら、サブフォームを再クエリする。
上記の前提では、テーブルの正規化ができいません。 場合によっては、テーブル設計から見直すべき事案かも知れません。
テーブル情報などの詳細が現時点では不明なので、その辺がはきっりしてから、アドバイスします。
りんごさん 質問者さんは初心者といわれています。 初心者にそのような回答をしても、もはや意味不明の回答だと思います。
Accessのテーブルやクエリのデータを貼り付ける場合は下記で、Markdown書式のテーブルに変換して貼り付けてください。
Markdown Tables generator
hirotonさん、hatenaさん
詳しい説明ありがとうございました。
リンク先の質問でも回答がありますし、今回もhatenaさんが回答していますが、
通常、32bit版ACCESSで作成したものが64bit版ACCESS環境で開けないのは、mde、accde形式のファイルです
ACCESSの基礎知識になりますが、ACCESSは2007から標準のファイル形式（の拡張子）がaccdbに変わりました。それ以前の標準のファイル形式（の拡張子）がmdbです
使用が推奨される Access ファイル形式
mdbやaccdbの形式であれば、それを64bit環境で開けるか？というのは基本的に問題になりません（正常に動作するか？は別問題です）
「mdb→accdbに変換」すべきかどうかは、上記リンク先を参考に決定してください
これにたいして、mde、accdeの拡張子を持つファイルは、（それを表す名称は不明ですが）コンパイル済みのACCESSデータベースファイルになります
32bitACCESSでコンパイルを実行すれば、32bit環境で動作するデータベース、64bitACCESSでコンパイルを実行すれば、64bit環境で動作するデータベースになる（互換性はない）ということなのでしょう。これも、mde、accdeどちらの拡張子で保存するか？ということ自体は無関係なので、ファイル形式によって制限のある機能を考慮した上で決定する必要があります
（現状、mdb,mdeファイルが即座に排除されるという状況でもなさそうなので、特別新しい形式に保存しなおす必要はないというのが持論です）
の部分は64bitのAccessでも可能と思います。
昔のMDBファイル(32bit)を探してきて、実際に試してみましたが、変換できました。
mdb→Accdbに変換（32bitのAccess）
その後、AccdbをAccdeに変換する（64bitのAccess）
上記で理論的には動作可能ということでしょうか？
とりあえず32bitのAccessを入手して、変換してみます。
情報ありがとうございます。
私自身はruntimeは使いませんので、あくまでWEBで調べた情報と、エラーメッセージからの判断ですが、mde あるいは、Accde を作成した同じbit環境でないと動作しないということだと思います。
mdbがあり、その内容がAccdeと同じということなら、mdbをAccdbに変換してから、64ビット環境でAccdeに変換すればいいでしょう。
一番最初に作成されたのは「.mdb」のようです。
「mdb」→「accdb」または「mde」変換では問題は解決しないですかね？
そうなりますね。
もし、先方にAccdeにする前のAccdbファイルがあるなら、それを送ってもらって、
こちらでaccdeに変換すれば、 64bitで動作するようにできます。
なければ、諦めるしかないでしょう。
情報ありがとうございます。先方は以前のシステム管理者で現在はいないかたのようです。
現在は私がaccessの編集などをしております。
結論はOffice32bitをインストールを行うしか動作環境は作れないということで間違いないでしょうか？
runtimeは作成したときのビット数と同じでないと動作しないという仕様のようです。
https://zawazawa.jp/ms-access/topic/628 でもhirotonさんがリンクを紹介してますね。
ACCDEファイルが32Bit版と64Bit版で共有できない : Access
Office 32bit環境を用意するか、先方に64bitで作成しなおしてもらうことになるかと。
質問のリンク先
論理削除はアンチパターンなのか？ #MySQL - Qiita
で提示されているデメリットについて今回の案件で検討してみます。
パフォーマンスへの影響
現在レコード数が約5万件、月2～300件程度の追加、削除(キャンセル)件数3%程度
このぐらいのデータ件数なら、削除フラグフィールドにイデックスを設定しておけば、ほとんど影響ないとかんがえていいと思います。
クエリの複雑化
Accessではクエリはテーブルと同等に扱えます。
上記の回答でしたように、論理削除レコードを除いたクエリを作成しておいて、それを使えば、現象のクエリやフォーム、レポートの修正する必要はありません。
クエリも複雑化しません。
ユニーク制約に工夫が必要
リンク先ではusersテーブルのメールアドレスにユニーク制約(Accessでは「重複なしのインデックス」)を設定する場合を例に挙げてますが、おそらく今回の注文テーブルではそのようなフィールドはないのではないかと。
あったとしても、私の回答の方法では削除日時をフラグフィールドにしているので、複数フィールドインデックスでユニーク制約の設定は可能です。
ということで、今回の要件なら大きなデメリットはないかと思います。
会社のパソコンからは、他サイトに書き込み出来ない為、スマホの画像をコピーして貼り付けてみます。当方は、デスクワークは、殆どしていません。ですのでお時間を頂く事になります。宜しくお願い致します。
SQLはSQLビューで全選択してコピーして、貼り付けてください。
貼り付ける場合は、Markdown記法のコードブロックにしてください。
やり方は下記で説明していますので参照してください。
Microsoft Access 掲示板 の使い方 Microsoft Access 掲示板 - zawazawa
あと、レポートのデザインビューのスクリーンショットを「画像アップロード」してください。
ご返答ありがとうございます。クエリのSQLは、SQLビューをスマホで写真撮った物をアップしても良いですか？
「まずありません」ということは「絶対ない」ではない「わずかであるがありうる可能性がある」ということですよね。
Accessデータベースはファイルサイズ2GBの制限がありますが、それに達する可能性がないのなら、私なら削除せずに「削除フラグ」を立てておくという方法をとりますね。
インデックスを適切に設定されているなら、パフォーマンスにほとんど影響はないと思いますので。
OSに実装されている「ごみ箱」の機能と同等のもの実装するということをしたことがあります。下記でサンプルを紹介していますのでご参考に。
上記のサンプルでは削除日時フィールドを追加して、それがNullのレコードは生きているレコードと、日時が入力されいいるレコードは削除レコードとしています。
こうしておけば、例えば削除後X年経過したら自動的にテーブルから削除するとか、削除してもいいか確認するとか、、、運用に合わせてお好みに設計できます。
レポートのレコードソースのクエリのSQLを提示してもらえますか。
あと、レポート上のSum関数が設定してあるコントロールのコントロールソースに設定してある式、そのコントロールが設定してあるセクション名、レポートのグループ化/集計の設定も提示してもらえますか。
商品マスタの商品コード999(メインフォーム)と見積の商品コード999(サブフォーム)を親リンク子リンクすれば、>> 7に近い形になると思いますが、それじゃダメかしら？もしダメならば、どうしたいのかを簡易図(例、スクショ)と文章で説明していただけますか？
ご回答有難う御座います。1の例で行くと選択クエリに合計数を求めているフィールドが2つあり、その両方が空欄の時が総合計が空欄になります。両方とも空欄になる場合どういう風に抽出条件を書けば良いですか？is nullでも非表示できますが、
フィールドの構成を変えない場合の記述の仕方がわかりません。ご教授頂けますと幸いです。
「既存のデータベースであり、キャンセルのフラグがある」なら、キャンセルを抽出条件に使います。すでに運用中であり、仕様を完全に把握しているのでなければ、データの削除に対する影響がわかりません
「既存のデータベースであり、キャンセルのフラグがない」なら、集計に含まないとする条件をそれぞれ追加するしかないでしょう
「既存のデータベースであり、キャンセルを削除する」を考えた場合、今後の運用に問題はないでしょうか？それを正しく削除できますか？誰が、いつ、できますか？
hirotonの場合、設計段階として、Nullを数えるような仕組みを極力排除します。仕組みとしては、「現物票出力日」「出庫日」「梱包明細出力日」の他に「状態」フィールドを設け、「
-1;キャンセル;0;現物票未出力;1;未梱包;2;未出庫;3;出庫済み」とします。明確に目的のものを集計するのでミスが起こりませんキャンセルについては、「梱包まで済んでキャンセルになった」のようなそれをどうするんだ？という場合もあると思います。要求に合わせて「受注状態（キャンセル・受注・納品済み）」「作業行程（伝票未発行、未梱包、未出庫、出庫済み）」のように、複数フィールドで管理する場合もあります
-1からの連番にしてしまっているので設計段階で工程をしっかり把握しておく必要があることには注意が必要です。「状態マスタ」テーブルを作成して、数値に意味を持たせないのが正しい正規化ですが、末端の情報にそこまで神経質になって後から良かったと感じたことはそれほどないです
当たり前ですが、削除すべきデータは削除します（ミス登録とか）
「キャンセル」というアクションは「存在しなかったもの」として扱っていいモノでしょうか？そうであるならば、「キャンセル」というアクションが起きたときにデータを削除するようにすればいいです
「とりあえず削除フラグ」というやり方は削除フラグが問題の原因ではなく、「とりあえず」という妥協する姿勢が問題になるのです
およそ3%が問題のデータということですが、パフォーマンスが問題になった場合、不要分のデータが存在しなかったとするならば、問題が発生するまでの期間の3%の期間だけ延命できることになります
パフォーマンスが問題になるならば、もっと根本的な解決が必要です
りんご様
回答ありがとうございます。
ご指摘のとおり同等品商品コード1〜5いずれかに商品コードが対応した場合にサブフォームに表示されるようにしたいと考えております。
お手数ですがよろしくお願いいたします。
下記の２つの方法が考えられます。
>> 6
SQLのようなコードではなく、商品コードの事だったんですね。理解不足でしたね、すみません。
>> 5
例、見積テーブル
商品マスタの商品コード:999
見積の同等品商品コード1〜4:001,002,003,004,005
やりたい事は、見積テーブルの商品コードを開いたら、対応する同等品商品コード1〜5がサブフォームに表示される、みたいな感じかしら？
りんご様
ご指導ありがとうございます。
hatena様がおっしゃる通り初心者であまりわかっていません。これから少しずつではありますが勉強させていただきます。
またご助言をいただければ幸いです。
hatena様
回答が遅くなり申し訳ありません。
また、説明不足もあり大変失礼いたしました。
今回の件を再度ご説明させていただきます。
今回の件は、商品の見積もりのデータベース化を目的としています。メインフォームにて商品を表示させたときにサブフォームに同一商品見積一覧、もう一つのサブフォームに同等品見積一覧を表示させようとしています。
テーブルは商品マスタと見積の2つになります。
商品マスタのフィールドには、日付（日付/時刻型）、品目（短いテキスト）、メーカー（短いテキスト）、商品名（短いテキスト）、商品コード（短いテキスト）があります。
見積のフィールドには、日付（日付/時刻型）、商品コード（短いテキスト）、同等品商品コード１（短いテキスト）、同等品商品コード２（短いテキスト）、同等品商品コード３（短いテキスト）、同等品商品コード４（短いテキスト）、同等品商品コード５（短いテキスト）、価格（通貨型）があります。
なお、商品マスタの商品コードと見積の商品コードをリレーションシップしてあります。
メインフォームはフォームデザインにて商品マスタのフィールドと商品見積一覧のサブフォーム、同等品見積一覧のサブフォームを表示させてあります。
メインフォームのレコードソースはテーブルの商品マスタになります。
商品見積一覧のサブフォームのソースオブジェクトはテーブルの見積でリンク親フィールドならびにリンク子フィールドは商品コードにしてあります。
同等品見積一覧のサブフォームのソースオブジェクトはテーブルの見積でリンク親フィールドは商品コード;商品コード;商品コード;商品コード;商品コード、リンク子フィールドには、同等品商品コード１;同等品商品コード２;同等品商品コード３;同等品商品コード４;同等品商品コード５にしてありましたが同等品は表示されませんでした。
拙い説明ではありますが以上になります。また、不足している場合があるようでしたらご面倒をおかけしますがご指摘をよろしくお願いいたします。
hatenaさんの仰る通りの状況です。もし、レポートを弄れるとしたらどうすれば良いでしょうか？
SUM関数の集計がレポートのレコードソースのクエリにあるのなら望みはありますが、
レポート内のテキストボックスで=Sum([フィールド名])などとしている場合は、
レポートを一切触る権利が一切ないなら無理ですね。
DoCmd.OpenReport の引数のフィルターに合計が文字列0を指定すれば出来るのか試してみます。ありがとうございました。
レポートを一切触る権利が当方には有りません。当方が、作ったレポートでは無い為でかつ長年そのフォーマットで運用してきた為です。空欄が出るのは、お客様が休業日で注文が無かった場合発生し、レポートにある総数量を求めるSUM関数が0の時空欄になります。ですので、受注次第で総数量が0の時は変動し、無駄紙となります。帳票の構造は、テーブルに注文のあったメーカーの注文数をフォームを通してテーブルに入力していく構造です。総数量の合計0を取得できればよいのですが。毎日の印刷枚数は、200前後で平日は、無駄紙が余り発生しないのですが、連休が絡むと細々と発生します。
現状、手作業で無駄紙を破棄しているのなら、
手作業にはなりますが、プレビューで無駄紙のページ数を確認して、印刷するときに無駄紙を除いたページを指定して印刷すれば、用紙の無駄遣いは抑制できますね。
レポートにいっさい手を付けることができないという状況でしょうか。
私が提案したレポートのイベントを利用することも含めて。
そもそもなぜ、空欄のページで出るのか、その仕組みが不明です。データがないものは出力されないのが通常ですので、なんらかの特別の方法をつかっていると思うのですが、どのような方法を使っているのか提示できませんか。
レポートのレコードソースのクエリにも手を付けられないのでしょうか。
抽出条件を設定することで、空欄の出力を抑制できるのなら、
DoCmd.OpenReport の引数にフィルターを設定できるので、それを利用できるかもしれません。
あるいは、空欄になるページが事前に取得できるなら、DoCmd.PrintOut で印刷するページ数を指定できるので、空欄以外のページを印刷するようにはできます。
どちらにしても、提供されている情報からは、これ以上の具体的な提案は難しいですね。
ご返答誠に有難う御座います。無駄紙は、いつも廃棄しており、経費節減の為何とかならないかと考えていました。総数量の座標が空欄の時をvbaやCOM等で取得しvbaで具現化できればと考えていました。vbaは、accessから独立しておりクエリ等を弄るのでは無く違った方法で出来るのではと考えておりましたが、もし可能であっても相当難しそうですね。
hirotonさんの回答でほとんど網羅してますが、少し補足を。
標準モジュールから、プレビューされたものを制御することはできないでしょう。
イベントをハンドルすることが可能なら、レポートの「フォーマット時」イベントで
Cancel = True とすれば、そのセクションの出力をキャンセルできますので、それを使うことができるかもしれません。
要件が不明瞭ですね
何がよくて何がダメなのかわかりません
お客様の要望で無駄紙なのでなくしてもいい・なくしたいなのでしょうか？
すべて空白でも必要な書類というものもあるので、ここまでの話では、手を入れてはダメなのでは？と思います
普通、出力不要なモノはレコード単位で出力を制限します（データベースなので）
これを制御するならクエリです（または、そもそも数量のないものはテーブルに記録されないので出力されません）
レポートの書式を一定に保つならば
余白に応じて行数指定無く用紙の最後まで罫線を出力する（hatena chipsさん）
書式を一定に保つ手法はアプローチがいくつかあるので使いやすいものを検討すると良いです
これは「レポート」を変更（改修）することになります
上述した通り、そもそも存在しないものが出力されている状態が疑問です。何かそうしなければならない理由とそれを実現するために構築したレポートの仕様があるはずです
特殊な事情があるのであれば状況や仕様の説明がなければ解決案も出せません
各ページに出力される項目が固定ならば、事前にその項目のグループで集計を行って、出力のあるグループだけをクエリで抽出すれば実現できると思います
ACCESSはデータベース管理ソフトです。データを効率的に管理、運用するために、テーブル、クエリ、フォーム、レポートを相互に連携させながら適切なデータ構造の構築、操作の制限、処理の最適化を行っていきます。これらを「変更できない」では何もできません。「ACCESS」がどのようなアプリケーションなのか、正しい理解と、お客様とのすり合わせを行って、何をしたいのか、何故それがダメなのか、本当にそれが望んでいることなのか見極めてください
あー確かに。すごくわかるんですけど、経験不足などでこの回答は難しいです。
hatenaさん、hirotonさん、skさん・・・だったかな、もっと詳しい回答者の方々、お願い♪
ご返答有難う御座います。レポートは、空欄ありきになっています。そのレポートは、お客様の要望の構成になっており、いじる事が出来ません。総数量欄が空欄のページの取得が出来るだけでも助かるのですが、難しいでしょうか？
レポートが元々空欄マスありきになっていて、問題が発生している場合、そうならないように新しいレポートを作成するのはどうでしょう？
レポートのレコードソースに元々不要なものが含まれていて、問題が発生している場合、レコードソースを遡って、フォーム・クエリ・テーブルを改善するかな。
ご返答有難う御座います。テキストファイルにvbaのコードを貼り付けて、標準モジュールに貼り付けて実行を考えていましたが、特殊なイベントをハンドルする必要がある場合は、許可を貰えば可能です。変更が難しいのは、レポートを構成する要素でテーブル、クエリ、レポートは、難しいです。
因みに、この様な無駄紙を発生させたくない場合、一般的には、どの様な手法を取るのでしょうか？
印刷プレビューを呼び出す前後で直接外すのは難しいでしょう。
変更を加える事が出来ないようになっているのであれば、例え可能であったとしてもレポートに変更を加えるVBAは控えたほうがよろしいのではないかしら？
不明な点は推測で補って、下記のようだと仮定すると、
サブフォームのレコードソースは「コードをいれるフィールドが5つあるテーブル」
テーブル名 Tbl1
5つのフィールド名 Code1, Code2, Code3, Code4, Code5
メインフォームにコードを入力するテキストボックスが一つある。
メインフォーム名 MF1
テキストボックス名 txt1
このテキストボックスのコードがCode1～Code5のいずれかと一致しするレコードを抽出する。
だとしたら、
Tbl1からクエリを作成して、デザインビューで下記のように設定
今回の条件はOR条件ですので、抽出条件は上記のように行をかえて設定します。
ちなみに、親リンクと子リンクの設定ではAND条件になりますので、今回の要件では使えません。
このクエリをサブフォームのレコードソースにする。
txtコードにコードを入力したら、サブフォームを再クエリする。
上記の前提では、テーブルの正規化ができいません。
場合によっては、テーブル設計から見直すべき事案かも知れません。
テーブル情報などの詳細が現時点では不明なので、その辺がはきっりしてから、アドバイスします。
りんごさん
質問者さんは初心者といわれています。
初心者にそのような回答をしても、もはや意味不明の回答だと思います。