Private Sub タブ1_Change()
Select Case Me.タブ1.Value 'Value=表示されいるページ番号(0から始まる)
Case 1 '2ページ目
With Me.サブフォームコントロール1
If .SourceObject ="" Then .SourceObject ="サブフォーム1"
End With
Case 2 '3ページ目
With Me.サブフォームコントロール2
If .SourceObject ="" Then .SourceObject ="サブフォーム2"
End With
Case 3
'略
End Select
End Sub
SELECT
MT_test.[クラス], MT_test.点数
FROM
MT_test INNERJOIN(SELECT[クラス]FROM MT_test
WHERE 点数=100GROUPBY[クラス]HAVINGCount(点数)=1)AS Q1
ON MT_test.[クラス]= Q1.[クラス];
Private Sub cmdFilter_Click()
Dim strFilter As String
If Not IsNull(Me.申込開始日検索) And Not IsDate(Me.申込開始日検索) Then
MsgBox "日付ではありません。"
Me.申込開始日検索.SetFocus
Exit Sub
End If
If Not IsNull(Me.申込終了日検索) And Not IsDate(Me.申込終了日検索) Then
MsgBox "日付ではありません。"
Me.申込終了日検索.SetFocus
Exit Sub
End If
If Not IsNull(Me.入金開始日検索) And Not IsDate(Me.入金開始日検索) Then
MsgBox "日付ではありません。"
Me.申込開始日検索.SetFocus
Exit Sub
End If
If Not IsNull(Me.入金終了日検索) And Not IsDate(Me.入金終了日検索) Then
MsgBox "日付ではありません。"
Me.申込終了日検索.SetFocus
Exit Sub
End If
If Not IsNull(Me.申込開始日検索) Then
strFilter = strFilter &" AND 申込日 >= #"& Me.申込開始日検索 &"#"
End If
If Not IsNull(Me.申込終了日検索) Then
strFilter = strFilter &" AND 申込日 <= #"& Me.申込終了日検索 &"#"
End If
If Not IsNull(Me.入金開始日検索) Then
strFilter = strFilter &" AND 申込日 >= #"& Me.入金開始日検索 &"#"
End If
If Not IsNull(Me.入金終了日検索) Then
strFilter = strFilter &" AND 申込日 <= #"& Me.入金込終了日検索 &"#"
End If
If Not IsNull(Me.使途検索) Then
strFilter = strFilter &" AND 使途='"& Me.使途検索 &"'"
End If
Me.Filter =Mid(strFilter,6)
If strFilter ="" Then
Me.FilterOn = False
Else
Me.FilterOn = True
End If
End Sub
入金日が確定していない場合、どうしますか？
入金日の抽出条件を入金開始日から入金終了日またはIs Nullとすると、入金日未確定のレコードを絞り込めなくなります。申込日で絞り込んでも、またはIs Nullだから復活、困りますね。これをクエリ1とします。
最終的に、クエリ1をもとにクエリ2を作って、申込日で絞り込むようにしました。これもセオリーがあれば、誰か教えて下さい。
入金日未確定を含めない、入金び日未確定を含める、入金日未確定のみと、切り替えるにはどうすればいいか？
まだ途中ですが、確定を1、未確定を2として、Switch(ほにゃらら,1) Or Switch(ほにゃらら,2) Or (Switch(ほにゃらら,1) Or Switch(ほにゃらら,2))みたいな事をやってみました。Switchを使わずにもっと上手い方法がないかなぁ。
最後に余談ですが、商品・サービスと顧客で申込日などが決まるテーブル、商品・サービスと顧客と年月で請求日や入金日が決まるテーブルみたいになると、どうでしょうか？
参考になるか分かりませんがACCESS+SharePointの環境で
テーブルのレコードを選んで削除→消える
選択クエリ（結合なしで抽出条件だけ）のレコードを選んで削除→クエリ上では消える、テーブルでは消えず、クエリを開きなおすとデータが消えていない
というのは経験したことがあります
深く検証する状況になかったのでこれ以上のことはわかりませんが、基本に立ち戻って最小構成のテスト用DBからどの状況でその現象が発生するのか確認したらいいと思いますよ
ご回答ありがとうございます。
Q_案件にてレコード削除した際も同じ現象が起きました。
一度削除される（削除しますか？のポップアップ⇒はいで、レコードが見えなくなる）のあとに更新ボタンを押すと復活していました。
フォームのレコードソースに、Q_案件 というクエリが設定されいるということですか。
このQ_案件を直接開いてレコード削除したときは、削除できますか。
また、データの更新はできますか。
結合することで、削除したものが復活するということはありえません。
結合や主キーの設定が間違っていると更新できない（当然削除もできない）クエリになることはあります。
例えば、セルを編集してセにしたい。
セルのルを消したのに、うっかりESCキー押してしまい復活しちゃった。
これに近い事が起きていませんか？当て推量ですが、何某かのイベントが発動して、編集が確定されずにキャンセルされているとか。
エラーメッセージの表示設定を一時的にONにして、リレーションシップの連鎖削除が原因と出てくるか試してみましたか？(フォームで削除出来ないものが、テーブルで直接削除出来るとは考えにくいんですが、念のため確認して下さい。)
名前が変わってました…どんぐりず＝風（質問者）です。
この修正について社内で後回しにしており、改めての質問になり申し訳ありません。
リレーションシップで、T_案件が「一対多」の「多」側になっていることがあります。そこで連鎖削除等の３つのチェックボックス全てにチェックを入れているのが問題でしょうか…？勝手な推測で失礼いたします。
これで削除はできませんでした。（一旦できるのですが、更新すると復活する）
色々と入り組んでいてどこまで説明すれば良いのかわからないのですが
F_案件の元データがQ_案件で
キーとなる「案件NO」からQ_案件で
「T_案件リンク」と「Q_サブ保守」に結合しています。
その他キー以外の
「売区」から「T_売区」
「得意先ID」から「Q_得意先」に結合しています。
色んな所と繋がっているので、削除しても復活してしまうのかと考えています。
全体的にボリュームのあるデータなので全て説明するのが難しく
適当な情報をピックアップしてしまい申し訳ありません。
リレーションシップは昔組んでいたらうまく行かない所があって
中途半端に組んでしまっています。
全部のテーブルを入れて、きちんと組むべきでしょうか。
ご回答ありがとうございます。該当のチェックボックスにチェックは入っていません。
入れた方が良いということでしょうか？（別の場所で色々不要なメッセージが出て驚かせてしまうので外した記憶があります）
MSの公式ドキュメントだと、下記にそれらしき記述がありますね。
あと、Now() とか結果が固定されていない関数などは使えないことからも更新時に結果を保存していて、呼び出し時に再計算はしていないと推測できます。
最後のリンク先は知らなかったので非常に参考になりました。
ただ、リンク先でも言及されてますが、インデックスを設定できないので、メリットは大きく減少していると思います。
パフォーマンスアップに関してもリンク先では200万行で実験していますが、私自身はこのような大きなデータを扱うことはないので、たぶん使用することはないだろうと思います。
おお hatena 様、いらしてくれてありがとうございます。
どうもはっきりしないのですが、
https://hamachan.info/win7/access/data.html
>Access2010では、テーブルのデータ型に［集計］が追加され、テーブルに集計フィールドを作成できるようになりました。
>計算の結果は集計列に格納されます。
https://358dokari.com/access-datetype-kaisetu1#⑭_集計
>14 集計
>他の列の値を参照して式を作成し、その計算結果をテーブルに保存することができます。
それとこの英語サイトが table と query の場合でベンチマークをやって、
「結果の値を保存している」と判断しているようです。
https://codekabinett.com/rdumps.php?Lang=2&targetDoc=access-table-calculated-field-compute-quarter-date
hatena 様はどうお考えでしょうか。
「保存する」説のページのリンクをいくつか提示してもらえるとありがたいです。
すみません、自己レスです。
MS公式その他を読んでも分からなかったので質問させていただきましたが、
検索を続けると「保存する」が多数説で判明しました。
お騒がせしました。
表形式のレイアウトが適用されているか否かによるのではないかと。
レイアウトが適用されているのであれば、レイアウト内で横並びになっている
複数のテキストボックスを選択し、それらの[左スペース]プロパティの値と
[右スペース]プロパティの値の和が 0.5 cm になるよう、プロパティシートから
それぞれのプロパティの設定値を入力すればよいはず。
りんご様
前提をお話していませんでしたが、表示するだけではなく、60万件ほどの初期レコードに対し、
UI上に演算等をするコマンドボタンが10数個あり、レコードを追加、削除、演算をし、結果として、
集計結果（100万件）をクロス集計クエリを表示する仕様です。
hatena様
インデックスは早速試しました、体感レベルですが少なからずパフォーマンス改善したように思います。
SourceObjectを空にしておいて、タブの移動で計算させるというのは、パフォーマンス改善にかなり有効でした。
どうもありがとうございました。
お二人ともありがとうございます。
フィルタの方で成功しました。クエリの方もいくつかのパタンは試したのですが、ご教示いただいた内容も試してみたいと思います。
またよろしくお願いいたします。
特に問題ないと思いますが、気になるなら、仮のテーブルとクエリを作って試してみるのはどうでしょう？
全部のフィールドを選択して、プロパティシートの書式、右スペースを0.5にするとどうなります？
おおぅ、お見事です。
工夫すればいろいろ方法はあると思います。
例えば、
まずは、横1列のテキストボックスの間隔0になるようします。
現状、各テキストボックスが重なるように配置されているなら、すべてのテキストボックスを選択して、
[サイズ/間隔]-[左右の間隔を均等にする]をクリック。
間隔が空いているなら[サイズ/間隔]-[左右の間隔を狭くする]を間隔０になるまでクリック。
間隔0になったら、右端のテキストボックスを選択して、[左位置]の値を間隔×(テキストボックス数-1)分だけ増やします。
例えば、間隔5mmでテキストボックス数１0なら 0.5×９＝4.5cm増やします。
その後、すべてのテキストボックスを選択して、[サイズ/間隔]-[左右の間隔を均等にする]をクリックすると、5mmの間隔になります。
テキストボックスがどれだけ多くても左位置の設定は1回ですみますのでかなり楽できます。
5cmと3cmのフィールドなどバラバラのサイズで各5mm開ける、とかだと、フィールドの長さを考慮して地道に打ち込んでいくということですか？
フィールドの左端位置は数値でわかりますが、右端（終わりの場所）の情報がないようなので
やはり手動で計算していかないといけませんよね
配置しているフィールドもすべて手動で書き換える必要がありますか？
同じテーブルのデータを表示させるだけなのでフィールドはそのままでよいのでしょうか？
テーブルに適切なインデックスは設定されているでしょうか。
列見出しに設定するフィールド、抽出条件を設定するフィールド、並べ替えを設定するフィールドにインデックスを設定してみてください。
複数のテーブルを結合しているなら結合フィールドにもインデックスを設定してみてください。
フォームに関しては、デザインビューでは、タブの最初に表示されいるページのみにソースオブジェクトを設定しておいて、ページを変更したときにそのページのソースオブジェクトを設定するという方法が考えられます。
コード例
それはそうでしょう。詳しくないですが、Excel風に印刷したい時など、その場限りで使うものではないでしょうか。クロス集計結果をメイン画面に表示して普段使うならば、Excelでデータベースを組むでしょう。
時間と労力を費やしてその場凌ぎではどうにもならないと思います。個人の意見なので、解決策が他にあるかもしれませんが。
現在のフォームを作成した後、元のテーブルを編集し直したが、そのせいか？取り敢えず、もう１つテーブルもしくはクエリからフォームを作ってマクロを試してみると、どうなるでしょうか。
あと、マクロのWHERE条件式ですが、
[開くフォーム上のフィールド名]=[Forms]![フォーム名]![テキストボックス名]
というフォーマットになりますが、[F_詳細]のレコードソースに[ID]フィールドは存在してますか。
これはテキストボックス名ではないので注意してください。
バラメータのテキストボックスの標題は何が表示されてますか？
そこに表示されているフィールドまたはオブジェクトが見つからないということですので、それに間違いがないか、開いているか確認して下さい。
それ以外の原因はないです。
>りんごさん
ありがとうございます。再度確認しましたが、テキストボックスの名前は間違いありませんでした。
以前にテーブルでIDフィールドを作成し直していますが、その影響はありますでしょうか。両フォームでのテキストボックスのコントロールソースに間違はないです。
当て推量ですが、打ち間違い、もしくは、もともと存在したけど名前が変わってしまったのではないでしょうか？例えば、見た目はIDと表示されているけど、テキストボックスの名前をプロパティシートで確認すると、IDD、みたいな。
入力支援機能を活用すると良いですよね。[Forms]![F_一覧]まで入力、次に！を押すと候補が表示されると思います。
ご丁寧にありがとうございました。
最初の方法でやります。スキルがないので。
フォームの場合、フィールド数100程度であれば、プロパティシートの数値を手作業で調整入力します。フィールド数1000程度になると、サイズと位置をVBAで調整入力したいと思います。以上、個人的な意見です。時間と労力に見合う方法を選べばいいんじゃない。
7mm、8mmくらいでしたら、配置タブのサイズ/間隔から広めを選んで出来そうです。
レポートの場合、詳しくないので他の方に聞いて下さい。
無理して一気にやろうとせずに、やりたいことを分解して、1つずつ実現するようにすればどうでしょう。
ということなので、まずは、グループ毎の100点の人数を取得するクエリを考えます。
下記のような集計クエリで取得できます。
結果は下記です。
このカウントが１のレコードを抽出したいのですから、カウントの抽出条件を１に設定します。
このクエリのSQL
このクエリ(Q_100_1)とMT_testを結合すればご希望の結果になります。
クエリを一つに纏めたいなら、それぞれのSQLをサブクエリを使ってまとめて、整理すると下記のようなSQLになります。
そのフォームにコマンドボタンを配置して、そのクリック時でレポートを開くようにして、引数で条件を設定するといいでしょう。
例えば、日付を条件に抽出するなら、
DoCmd.OpenReport メソッド (Access) | Microsoft Docs
当て推量ですが、レポートのレコードソースをテーブルからクエリに変更して、もう一度整えるのはどうでしょう。
コード例
入金日が確定していない場合、どうしますか？
入金日の抽出条件を入金開始日から入金終了日またはIs Nullとすると、入金日未確定のレコードを絞り込めなくなります。申込日で絞り込んでも、またはIs Nullだから復活、困りますね。これをクエリ1とします。
最終的に、クエリ1をもとにクエリ2を作って、申込日で絞り込むようにしました。これもセオリーがあれば、誰か教えて下さい。
入金日未確定を含めない、入金び日未確定を含める、入金日未確定のみと、切り替えるにはどうすればいいか？
まだ途中ですが、確定を1、未確定を2として、Switch(ほにゃらら,1) Or Switch(ほにゃらら,2) Or (Switch(ほにゃらら,1) Or Switch(ほにゃらら,2))みたいな事をやってみました。Switchを使わずにもっと上手い方法がないかなぁ。
最後に余談ですが、商品・サービスと顧客で申込日などが決まるテーブル、商品・サービスと顧客と年月で請求日や入金日が決まるテーブルみたいになると、どうでしょうか？
フィルターは使った事がないので、選択クエリでやってみます。
日付の抽出条件をBetween [Forms]![フォーム名]![申込開始日検索テキストボックス] And [Forms]![フォーム名]![申込終了日検索テキストボックス]とします。
抽出条件の範囲指定をNz([Forms]![フォーム名]![申込開始日検索テキストボックス],100/01/01)、Nz([Forms]![フォーム名]![申込終了日検索テキストボックス],9999/12/31)と変更します。
ここはセオリーがわからないので、アドバイスがあればどなたかお願いします。
選択クエリからフォームを作成し、検索テキストボックスを配置、更新後VBA処理にフォームの再クエリ、こんな感じでどうでしょうか？
とりあえず下記を参考にチャレンジしてみては。
複数条件の抽出フォームの設計 その1 - hatena chips
データベースがやりたいわけじゃない、自動入力がやりたい、レポートを印刷したいという事でしたら、Excelで自動入力する方法、ワードにインポートする方法を検討してみるのはどうでしょうか？
データベースがやりたいという事でしたら、複合主キーや複数テーブルを頑張るしかないですね。
日付テーブルは作らずに始めてもいいんじゃない。点呼記録テーブルは、日付と従業員の複合主キーを設定する感じでしょう。
いずれにしてもIDでの主キーはつくらずに日付でやっても問題ないということになりますか？