Private Sub cmd車庫証明Open_Click()
If Nz(Me.cmb普軽) = "" Then
MsgBox "「普通車」または「軽自動車」を選択してください。"
Exit Sub
End If
DoCmd.OpenForm "F車庫証明"
With Forms!F車庫証明
Select Case Me.cmb普軽.Value
Case "普通車"
.普通車.Visible = True
.普通車.SetFocus
.軽自動車.Visible = False
Case "軽自動車"
.軽自動車.Visible = True
.軽自動車.SetFocus
.普通車.Visible = False
End Select
End With
End Sub
Private Sub cmd車庫証明Open_Click()
If Nz(Me.cmb普軽) = "" Then
MsgBox "「普通車」または「軽自動車」を選択してください。"
Exit Sub
End If
DoCmd.OpenForm "F車庫証明"
With Forms!F車庫証明
Select Case Me.cmb普軽.Vlue
Case "普通車"
.普通車.Visible = True
.軽自動車.Visible = False
Case "軽自動車"
.普通車.Visible = False
.軽自動車.Visible = True
End Select
End With
End Sub
「元から ElseIf ブロックのコードがモジュールに記述されていた（が、最初の投稿時に端折っただけ）」とおっしゃりたいのか、「実際にはモジュールに記述されていなかったのでコードを修正した」という意味でおっしゃっているのか、どちらなのでしょうか。
仮に前者であるとして、
現時点では以下のいずれの意味でおっしゃっているのかが不明瞭です。
レコードの並べ替え順が Sort プロパティで指定した通りにならず、[残業管理ID]が 130 であるレコードの次のレコードが 85 のレコードとなり、更にその次のレコード以降に 95 のレコードが現れる。
レコードの並べ替え順は Sort プロパティで指定した通りになっているが、ElseIf ブロック内で呼び出された DCount 関数の戻り値が 0 となる（ので[残業区分]の書き換えとレコードの更新が実行されない）。
レコードの並べ替え順は Sort プロパティで指定した通りになっているが、[残業管理ID]が 95 であるレコードを参照した際、最後の rs.MoveNext メソッドが呼び出されるより前のいずれかのタイミングで次のレコード（ 85 ）に移動している。
それどころか、レコードセットの中に[残業管理ID]の値が 95 であるレコードが含まれていない。
上記以外の意味。
例えば 1,2 のいずれかに該当するならテーブル[tbl残業管理]の各レコードの[日付]に格納されている実際の値（例えば日付だけでなく時刻が含まれていないか等）を確認すべきですし、3 に該当するなら「（途中略）」とされた部分全てのコードが疑惑の対象となります。
申し訳ございません。
コードの一部を追加しました。
残業区分 = 2の時の処理を記述しました。
コードが途中までしか記述されていないので実際にどのような動作をしているのか読み切れませんが、本当に飛ばされているのか確認のテストコードを実行してみるといいと思います
たとえば、
Do Until rs.EOFの次にそれ用のコードを記述します詳しい確認方法などは参考サイトがたくさんあるので適当に覗いてみてください
https://www.google.com/search?q=VBA デバッグ
[残業管理ID]の値が 95 であるレコードの[残業区分]の値は 2 であり、上記の条件を満たしていないため。
標準機能の「印刷」はそういった操作を考慮しないただの「印刷」のみの機能ですね
「なんやかんやしつつ、『印刷』もして、なんやかんやする」という機能を独自に実装する必要があります
レポートの印刷プレビューウィンドウにボタンを配置する（hatena chipsさん）
Access でカスタム リボンを作成する
とりあえず一例としてリンクを挙げておきますが、汎用性を持たせようとしたり、要求によっては高度な知識や複雑なコーディングが必要になったりします
具体的な肝の部分だけ言えば
という2行のVBA/マクロを実行するだけでしょう
For文のループ内にDoCmd.GoToRecord , , acNextをいれるというようなことはしたことがないので原因は分かりませんが、
たぶん、もっと効率的かつ高速かつ安全な方法があると思います。
具体的にどのようなことをしたいのか説明されたら、具体的なアドバイスでつきそうです。
表示されている全レコードを更新したいとかなら、更新クエリで更新するとか、フォームのRecordsetプロパティを使って更新するとか、いろいろな方法があります。
素晴らしいです。作業が進みそうです。
ありがとうございました
すみません。タイプミスです。下記に修正してください。
Selecl Case Me.Cmb普軽.Value
メッセージ通り、開いた直後は普通車ページにフォーカスがあるのが原因ですので、軽自動車ページにフォーカス移動させればいいでしょう。
hatena様ご教示の通りやってみましたが次のようなエラーが出ました。
selecl case me.cmb普軽.vlue
のvlueの部分でメソッドまたはデータメンバーが見つかりませんと出ます。
一応その部分を消してクリックした場合普通車の部分は開くのですが
軽自動車を開くときはコントロールがフォーカスを取得しているときはコントロール
を非表示にすることはできませんと出ます。
よろしくご教示のほどお願いします。
試験勉強しなきゃいけないのに、模様替えが気になっちゃうパターンかしら？レポートやレイアウトのポンチ絵の前にやるべき事に集中しないとね。
実際にどのような流れや方法によってデータ入力が行われることになるか、またどのような勤務形態を前提としているか、どのようなルールに基づいて給与計算を行うか――といった諸々の問題が関わってきますので、正解はないでしょう。
例えば「出退勤時にタイムカード（紙）に打刻する」方式と「ICカードリーダーによって入退室管理を行う（直接電子データとして記録される）」方式とでは勝手が違いますし、また深夜/早朝に渡る勤務が当たり前に発生することを前提としているか否かによっても考え方は変わってくるでしょう。
後者のレイアウトにデメリットがあるとすれば、ごくシンプルに「日付ごとの勤務時間の計算がしにくい」という点が挙げられます。
前者のレイアウトであれば、基本的にはレコードごとに[退勤時刻]と[出勤時刻]の差を求めるクエリを作れば済みますが、後者のレイアウトは[出勤]と[退勤]のレコードが別々に記録されることになるため、多少手間がかかります。
また出勤時と退勤時のいずれかにおいて打刻忘れが発生し得ることを想定した場合、[出勤]と[退勤]のレコードの組み合わせを得るための手順は複雑化するでしょう。
出勤と退勤は一対(出勤だけ、退勤だけというのは通常はない)のものなので、それを１レコードすると考えるか、
時刻データで種類のことなるものなので別レコードにすると考えるか、
データベース的にはどちらもありです。
それぞれメリット、デメリットがあるので運用や処理においてどちらが使いやすいかで決めればいいと思います。
人間が見たときに、見やすいのは前者ですが、後者でもクロス集計クエリで簡単に前者の形に変換できます。
レポートで出力するときは、「重複データ非表示」プロパティで簡単に、下記の見た目にすることもできます。
2024/04/25□AAA□出勤□9:00
□□□□□□□□□□退勤□17:00
□□□□□□□BBB□出勤□9:00
□□□□□□□□□□退勤□17:00
前者の設計が多いのは、
勤怠管理で一番多い処理は、勤務時間の集計だと思いますが、
前者だと、退勤時間-出勤時間 で簡単に計算できるからだと思います。
日付をまたぐ場合の対応は、日付も持たせるか、退勤時間<出勤時間 なら24時間足すという対応でもいいでしょう(24時間以上の連続勤務はないと思いますので)
後者でもクロス集計クエリで前者の形に変換できますので、それで同様のことは可能になります。ただし、クロス集計クエリを間にいれることでパフォーマンスに影響があるかも知れません。
結局、データ入力をどうするか、次第ではないかなと。
例えばタイムカードを使っているなら、それが出力する形式に合わせるとか(たいてい前者のレイアウトになっているかな？)
了解しました。
まず、
フォーム名「選択」
テキストボックス名「普軽txt」
上記のテキストボックスを右クリックして「コントロールの種類の変更」で「コンボボックス」を選択します。これでコンボボックスに変更できます。
このコンボックスのプロパティを下記のように設定してください。
名前 cmb普軽
値集合ソース 普通車;軽自動車
値集合タイプ 値リスト
入力チェック はい
リストの編集の許可 いいえ
コマンドボタンの「クリック時」の[イベントプロシージャ]を下記のように記述します。
コマンドボタンの名前は cmd車庫証明Open
ｈatena様久しぶりにお世話になります。
下記であってますか。
>>あっています。
コマンドボタンクリックですか、それとも入力したら自動的に実行されるようにしますか。
>>コマンドボタンクリックです。
テキストボックスではなく、コンボボックスでリストから「普」「軽」が選択できるような設計の方がUIとしては優れていると思いますが、そのような設計に変更してはどうでしょう。
>>変更します。
にはどのようなデータが必要でしょうか？
これも、よくある受発注データベースサンプルなんかを参考にしたらいいと思いますよ
「席」という商品を「予約毎に受け付ける」という形なので
「T_指定席予約データ」という一つのテーブルで何とかしようとするのではなく、
予約テーブルと予約席明細テーブル2つに分けて登録するとうまく正規化できます
あと、「普軽txt」に入力した後、質問の処理をどのように実行しますか。
コマンドボタンクリックですか、それとも入力したら自動的に実行されるようにしますか。
また「普」「軽」以外が入力されたらどうしますか。
テキストボックスではなく、コンボボックスでリストから「普」「軽」が選択できるような設計の方がUIとしては優れていると思いますが、そのような設計に変更してはどうでしょう。
説明があいまいな部分があるので、
状況を整理すると下記であってますか。
フォーム名「選択」
テキストボックス名「普軽txt」
フォーム名「F車庫証明」
タブコントロール名「普通車・軽自動車」
1ページ目のページ名「普通車」
1ページ目のページ名「軽自動車」
違っているなら、それぞれの正確な名前を提示してください。
日付を選択した瞬間にイベントを走らせるのに、Me.Refresh をするというのは目的のための道具の選択が適切でないということです。
例えると、大根を切るのに適切な道具は、包丁ですが、チェーンソーを持ち出して切る、というイメージです。
追記です。
'キー入力フラグがfalseのときはフォーム入力値を確定する
If Me![chk_date] = False Then
DoCmd.RunCommand acCmdSaveRecord
End If
こうする事で、日付を選択した瞬間にイベントが発生することができました。
保存したいとか、そういう理由はありませんが、そこで保存したことによって
問題もないですし、イメージ通りに動くことができたのでよかったです。
ありがとうございました。
おはようございます。
ご返信ありがとうございます。
http://hiroses.seesaa.net/article/397791059.html
上記のサイトでは
日付選択カレンダーで日付を選択した瞬間にイベントを走らせる事ができないので
Me.Refreshを入れていると思います。
詳しくはわからないのですが・・・
'キー入力フラグがfalseのときはフォーム入力値を確定する
If Me![chk_date] = False Then
'Me.Refresh
Call txt_date_AfterUpdate()
End If
こちらを試してみたのですが、日付を選択した瞬間には発生しなかったでした。
フォーカスが移動した瞬間には発生します。
色々ググってみてはみたのですが、日付カレンダーはで日付を選択した瞬間は、イベントが発生しないみたいです。
テーブルでの並び順を名前の昇順ということは、通常はあまりないことです。
主キーフィールド順にするか、並び替え用のフィールドを用意するのが普通の設計です。
#8の投稿のテーブルなら、正規化すると、
席種マスターテーブルと席列マスターテーブルを作成することになります。
正規化例
席種マスター
席種ID 席種
1 座席
2 パイプ椅子
席列マスター
席列ID 席列
1 前列
2 後列
ID 席種ID 席列ID 席番
1 1 1 １
2 1 1 ２
3 1 1 ３
・・・
20 2 2 Ｔ
どなたか分かりませんが、スタンプでは分かりませんので文章でお願い致します。
無事に昇順で表示させることができました。ありがとうございました。
どこまでがこの課題の必要情報か分からず、また社内情報保護の為小出しになってしまい申し訳ありません。
ここがよく分からないのですが、どういうことでしょうか？
ちなみに社内の既存のシステムなので、テーブル構成を変えるのが難しいです。
メインテーブルのレコードに全ての情報が集約されている感じのテーブル構成です。
T_指定席予約データ
何度かこのサイトで教えて頂いていますが、テーブルが「正規化」されていないから扱いにくいということですかね？例えば席関連のフィールドでいえば、T_指定席予約_席 のようなテーブルを作成して、そこに席関連だけのデータを格納しリレーションでつなぐ・・・といったことをしないといけないということですよね？
テーブル構成がどうなっているか不明なので、とりあえずの推測ですが、
IDをフィールドを最小か最大にすればいいのでは？
通常、コンボボックスのコントロールソースにはキーフィールドを格納するという設計になると思いますが、
このような質問が出てくるのは、その辺のテーブル設計がまずいのではという予感。
後だしで情報を追加していくのではなく、最初から関係するすべての情報を提示して質問してもらった方が、お互いに手間がないかと思いますが。
コンボボックスに同じ選択肢を羅列させないために集計でグループ化しているので、IDをフィールドに入れるとマズイ場合はどうすればよいでしょうか？
そのテーブルなら、ID の昇順にすればいいだけでは。
cmb_席2 の値集合ソースに下記のSQLを設定すればいいでしょう。
レスが遅くなってしまい申し訳ありません。
実際にはイベント会場の指定席管理システムを作っていまして、
このようなテーブルがあり、cmb_席種というコンボボックスから「座敷」を選択すると、cmb_席1コンボボックスの選択肢は「前列」だけになり、「前列」を選択するとcmb_席2の選択肢が１～２０になり、この際数字が昇順になるように表示させたいということです。
このため、席2フィールドに全角数字と全角アルファベットがあります。
そもそもMe.Refreshをする必要性が分からないのですが、なんのために必要なのでしょうか。
リンク先の説明では、日付選択カレンダーで日付を選択した瞬間に「更新後処理」イベントを実行したいということのようですが、そのために Me.Refresh は目的と手段があっていないように思います。
Refresh はカレントレコードの更新をテーブルに反映させて(=レコード保存)、かつ、テーブルデータを再読込するということですが、その必要性があるでしょうか。(再読込するので一旦非表示になる)
「更新後処理」プロシージャを実行したいのなら、それをCallすれば済む話です。
リンク先のコードなら、下記でいいとおもうのですが。
もし、日付選択カレンダーで日付を選択した瞬間にレコード保存(？)したいのなら、下記でいいですし。
(再読込はしないので非表示にはならない)
hatena様
ありがとうございます。
こちらもやってみます！
hirotonさんの回答と同じ考え方のものですが、下記にサンプルがあります。
ご参考に。
hiroton様
ご回答ありがとうございます。
そのやり方をやってみます。
見栄えや使いやすさなどをよく判断してみます。
基本的にはできないですね
コントロールBの前面にテキストボックスを配置して、背景スタイルプロパティを「透明」に、コントロールソースで
=IIf([テキストボックスA]<>1,"███")としてコントロールBを隠すとか、そんなことならできます前景色プロパティで、メインの背景と同じ色になるようにして、フォントの設定でうまく塗りつぶすようにします。境界線や立体表示、余白の設定なんかも調整する必要があります
コントロールによってはテキストボックスよりも前面に表示されるモノ（前後の優先順位が固定のコントロール）もあるので、それらに関しては打つ手なしだと思います
というようなテーブルデータとういことですか。
これはどのようなリストでしょうか。
データベース的な設計なら、主キー必須なので下記のような感じとかになるはずです。
で、主キーで並び替えます。
質問内容をあまり省略しすぎると、その内容に最適化された回答をしますので、
実際の処理に合わないものになる可能性が大きいです。
なるべく実態に近い質問内容にしてください。
例えば、前回の質問では、下記のようにいってますが、
もしこの内容なら、市町村コードというものがありますので、それで並び替えるとかになります。
説明不足で申し訳ありません。
ひとつ前の質問と関連するのですが、他のコンボボックスで選んだものによって選択肢が変わります。
例えば昇順に並べ替えたいコンボボックスがcmb_検索2だとすると、cmb_検索1でAを選ぶと１～２０が、Bを選ぶとＡ～Ｚがリストに表示されるといったような感じです。
ならばデータ例もそうのように提示すべきですね。
全角数字のあとにアルファベットがくるのですか。
であるなら、前回の回答の最初のクエリでいいでしょう。
商品コード的なもので、数字＋アルファベット という書式のものなら、
数字部分とアルファベット部分にわけて、それぞれ数値型、テキスト型フィールドにするという設計もあります。
というようなこともあるので、どのような書式になるのか、データ例もあげて、仕様を明確に提示してください。
同じフィールドにアルファベットが入る可能性があるので数値型に出来ません。
全角数字はVal関数では数値と判断されずに０になります。
StrConv関数で半角に変換してVal関数で数値化すればいいでしょう。
StrConv 関数 (Visual Basic for Applications) | Microsoft Learn
そもそも論ですが、数値順にならべたいフィールドを、テキスト型で全角数字にする意味が不明です。
素直に数値型のフィールドにしておけば無駄なことをせずにすみます。
StrConvやValで囲むことで無駄な処理が増えて、かつインデックスが無効になるので重くなります。
もし、表示上、全角にしたいのなら、フィールドのデータ型は数値型にしておいて、表示するときに全角に変換すればいいでしょう。
ありがとうございます！
思った通りに動かせるようになりました。
cmb_2の値集合ソースのクエリ(SQL)をcmb_1の値で絞り込んだものにします。
これだけだとcmb_1を変更してもリストが更新されないので、フォーカス取得時に再クエリします。