Private Sub 日付_AfterUpdate()
Me.日付.DefaultValue = “#” & Me.日付 & “#”
End Sub
Private Sub 名コード_AfterUpdate()
Me.名コード.DefaultValue = Me.名コード
End Sub
Private Sub 数量_KeyDown(KeyCode As Integer, Shift As Integer)
On Error Resume Next
Select Case KeyCode
Case vbKeyUp
DoCmd.GoToRecord , , acPrevious
Case vbKeyDown
DoCmd.GoToRecord , , acNext
Case Else
End Select
End Sub
「1または0、多または0のリレーションシップ」とはどのようなものでしょうか。
他のデータベースにはそのような機能かあるのでしょうか。
外部結合(OUTER JOIN)のことではないですよね。
とりあえずExcelみたいな何かになるけど、請求書を発行するときに、B業務テーブルの要レコードを絞り込み、追加クエリ。A業務テーブルの要レコードを絞り込み、集計クエリからの追加クエリ。みたいな感じで、請求書の明細欄テーブルに追加すれば、いいんじゃない？
それぞれメリット、デメリットがありますので、運用実態によるでしょうね。
テーブルは分けておいて、集計するときに、ユニオンクエリでまとめて、それから集計クエリにする。
メリット
現状のエクセルの表をそのままテーブルにすればよい。
デメリット
ユニオンクエリはレコード件数が多いと重くなりがち。
テーブルは一つにまとめておく。
メリット
ユニオンクエリを作る必要がなく、そのまま集計クエリにできる。
デメリット
片方のテーブルにしか必要のないフィールドもすべて持つ必要がある。
自分としては、
分ける方は、ユニオンクエリで重くなるのはどうしようもないが、
纏める方は、業務によって不必要のフィールドは、クエリや入力フォームを別に作成することでなんとでもなるので、
一つに纏める方がいいかと思います。
集計条件に該当するデータの入力があったとき（日々のデータ入力のとき）
VBAで集計条件の有無をチェックしつつSQLを発行して
hirotonならこうするだろうというたとえです。実際には要件に合わせていろいろでるでしょう
繰り返しますが
結局のところデータ構造自体はよくある「請求書」「請求明細」の構造と同じです。運用や作業性に合わせてどのようにシステムを組み込んでいくかという問題になると思います
「請求書を発行する」という目的があるようなので今あるデータを使って請求書を作ってみるといいでしょう。ACCESSで実現するために（データベース的な考え方として）何が必要か見えてきますし、そのうえで「では、新しい請求書を発行するためにはどのようなデータ構造、入力・処理が必要か」というのが見えてきます
ここまでが準備です。Excel(表計算)みたいな何かを作る企画がスタートします。
業者に発注して、Excelみたいな何かを作ってもらうのが、早いと思います。
基本的に、上から下に入力するのが、Accessだと思います。左右と上下に入力するのは、Excelみたいな何かでしょう。基本的に、持ち替え(根回し)を避けられないのがAccessだと思います。何も考えずに超スピードで入力出来るのは、Excel的な何かでしょう。
データモデリングがポンコツならば、遅かれ早かれ、不安定でどこかおかしいAccessになると思います。根回しがしっかりしていれば、AccessみたいなExcelがあってもおかしくないと思うのですが。
始めてみないとわからないと思いますよ？
テーブル作成、クエリ作成(テーブルのクエリ化)、フォーム作成(クエリのフォーム化)、集合形式から表形式に変更、高さ、上位置、左位置の微調整、単票フォームから帳票フォームに変更まで、頑張りましょう。
まず、テーブル作成ボタンを見つけて、データ型を選べますか？主キーのON/OFFを出来ますか？
次に、クエリ作成ボタンを見つけて、何をどうすればいいかわかりますか？テーブルを選んで、フィールドを選ぶだけですが。
最後に、フォームは、基本操作の解説動画を探して下さい。思い通りに移動させたり、大きくしたり小さくしたり、出来ますか？ワードやエクセルのように、雰囲気では無理です。
日付のプロパティ・・・・・既定値Date()
名コードのプロパティ・・・既定値ほにゃらら(数値型、短いテキスト型、既定値を決めて下さい。)
集計条件はいつ、どのように記録するのでしょうか？
品種コードですが、もしかして親テーブルから参照してきているのかしらと、私が早とちりしていました。ごめんなさい。
【解決】
リンゴ様
いつもありがとうございます！
教えて頂きましたコードで動作実現できました！！
「品名」に「品種コード」とリレーション・・・表現が間違ってました。
正しくは”両方とも同一テーブルで「品種番号」に入力したら「品名」に自動的に入力されるので・・・”でした。
紛らわしい表現をしてしまいすみませんでした。
早々のご回答ありがとうございました！
また、行き詰ったら宜しくお願いします。
お返事が遅くなってすみません。
ありがとうございます。
使えそうな時があったらぜひチャレンジしてみたいと思います。
具体例を挙げていただければそれに合わせて回答もできるんですがたとえば
のようなデータがあったとして請求書が
となるような場合なら
集計条件を記録するテーブルは
になります
ところで、これはどういう事でしょうか？
くわしい解説ありがとうございます
集計条件を記録するテーブルを用意、というのはどういったものですか？
理解できなくてすみません
前段階でクエリでデータを結合しておく、レポートにレポートを埋め込む仕組み（サブレポート）、VBAによる制御、等柔軟に対応する仕組みはあるので大抵のことはできますが、どの程度なら「かんたん」で済むのかは要件次第でしょう
ルールさえしっかりしていればできないことはないと思います。
ただ、請求書番号が未決定のレコードについて、新規で番号を取ればいいのか、集計で統合される別なレコードですでに決定されていないか、それらで請求書番号に矛盾がないか等の問題と対策が発生します。請求書番号は集計結果ごとの管理にしたほうが楽でしょう。
また、ちょっと難しい言い方になりますが、「印刷時に自動で請求書番号を決定するシステム」は難しいです。
プレビューで請求書番号を仮発行するのか、キャンセルした場合どうするのか、上記問題と合わせてどのような表示順にするのか
そして、これらを実現するための複雑な処理等、様々なことに悩まされることになります。
集計条件を記録するテーブルを用意してそこに条件を追加していけばいいです。集計結果自体は計算で求まるので記録する必要はないですし、そのテーブルに「請求書番号」フィールドを設ければ、集計結果の1レコードごとに「請求書番号」を管理することができます。
結局のところデータ構造自体はよくある「請求書」「請求明細」の構造と同じです。運用や作業性に合わせてどのようにシステムを組み込んでいくかという問題になると思います
りんご様、mayu様
ご指摘ありがとうございます。まだ頭の整理がキチンとついていないようです。
お恥ずかしい(/ω＼)
OLE DBドライバについてもインストール済みで、こちらを報告すべきでした。
やったことメモから適当に引いてご報告してしまいました。
結果的にmayu様よりアドバイスいただいた以下を追加することで、
64bit版Accessの帳票フォーム上にもADO接続の結果を正しく表示することが
出来ました!
知らないアイテムでしたので調べましたところ、rsの結果をクライアント側で
利用する事を明示するものなのですね。64bit版Accessで結果セットから.Nameアイテムを
利用する際にははしっかり明示する必要があるようです。
mayu様、とても助かりました。ありがとうございます。
ところでADO接続とDAO接続の違いについて、どちらもサーバーから結果セットのみ
取得できるようですので、Access上では親和性の高いDAO接続の方が良さそうですね！
DAOのリンクテーブルでは、テーブルデータを毎度引っ張ってきてローカルでキューされる
と勘違いしておりました。パススルー出来るのですね！
ウチのシステムもDAOにしておいてくれたら移行もすんなりだったのに…とも思いますが
今回の事は私にとってとても勉強になりました。
重ねてお礼申し上げます。ありがとうございました。
ありがとうございます
今はピボットテーブルで集計してその値をコピペして請求書を作っています
請求書には別のシートからコピペしたものもあります
ACCESSだと、クロス集計クエリで集計した結果と、他のテーブルのレコードを
請求書レポートに並べることになりますが、かんたんに混ぜることはできますか？
各レコードには請求書番号を付与して、再発行や確認に使う予定です
集計結果に請求書番号を付与することはできないと思いますし
請求書作成時に、大本のレコードすべてに付与することもむずかしいでしょうか？
集計結果を1つのレコードとして扱いたい場合は、一旦EXCELで入力、集計してインポートするのが
一般的でしょうか？
【解決】
hatena様
ありがとうございます！
おっしゃっている通りの動作が再現出来ました！
「VBAで値を更新した場合・・・」そうなのですね！？
大変勉強になりました。
今回も本当にありがとうございました！
再送ファイルを見てみました。
「F_受注_メイン」フォームのことだと思いましたので、そのフォームを開いて試してみました。
開いた直後は、取引先コードは未入力なので、サブフォームは操作できません。
取引先コードにコードを手入力したら、サブフォームは操作できるようになりました。
コードを削除したら、サブフォームは操作できなくなります。
メインでレコード移動して、移動先が取引先コードが未入力ならサブフォームは操作できない、入力済みなら操作できます。
問題ない動作のようです。
ただし、取引先コードの横にコマンドボタンがあり、そこから別フォームを開いて、取引コードを選択して入力できるようになっていますが、それで入力した場合、サブフォームは操作できるようになりません。
このようにVBAでテキストボックスの値を更新した場合、更新後処理は発生しないためです。
下記のように別フォームを開いた後で、更新後処理を呼び出せば、別フォームで入力したときも正常に動作するようになります。
解決、おめでとうございます。
>> 7
リストボックスは、難しいけれど、便利なので、練習しておくといいですよ。
連結列、コントロールソースの有無、列数、列幅、コード。
抽出条件やコードやキークリック時イベントは、初めてのときは、難しいかもしれません。
[Forms]![フォームの名前]![テキストボックスの名前]
Me.リストボックス1.Column(1)
DoCmd.OpenQueryからのMe.リストボックス1.Requery
Msgbox KeyCodeからのKeyCode 32(スペースキー)
知ってるよ、と問題なければ、やってることは、基本作業の積み上げです。
元のテーブルを作ったら何も考えずにクエリ化、リストボックスに表示。
絞り込めたら便利なので、テキストボックスを置いて🔑抽出条件
選択クエリを作って絞り込み追加クエリに変更、仮テーブルに追加して別のリストボックスに表示。
選択クエリを作って元テーブルと仮テーブルに線を引いて、更新クエリに変更、更新値に従って更新
最後に、単独主キーや複合主キーの設定は抜けていないと確認とれましたか？単独主キー、複合主キーがなければ、破綻しているので全部水の泡です。
クエリに式を作る方法で一つのレコードだけにチェックすることができました。
その発想はなかったのでありがとうございました。
アドバイスありがとうございます。
>> 6
出来たとしてもごちゃごちゃなりそうなのでイマイチですね。
大変失礼いたしました・・・。
再送しました。
宜しくお願いします。
アドバイスありがとうございます。
試してみます。
すみません。この方法は私には難しそうです....。
アドバイスありがとうございます
今回、搬入完と検査完の二つを例にしてあげましたが、他にももっとあります。一部搬入完や一部検査完、不適合など全部で6つぐらいあります。それでも同じようにできますか？
進捗報告みたいなプラットフォームなので複雑なんでしょうか。
ファイルを見ましたが、
「T_受注」と「T_受注明細」がリンクテーブルの為、フォームを開くことができません。
ローカルテーブルに変更したものを、再度、送付してもらえませんか。
最悪Excelのデータをリンクテーブルで読み込んでいるとかだと主キーがないこともあるんですかね
レコードソースをクエリにして
主キーのようなもの: [初期ID] & "_" & [データKEY]フィールドを作って単一のフィールドでチェックできるようにしたらどうでしょうhatena様
ありがとうございます。
ではファイルを送ります。
どうか宜しくお願い致します。
クロス集計クエリというものがあります。
フォームを作成してテキストボックスを配置すると規定値プロパティが使えるので、VBAでこれを制御するのが分かりやすいと思います
キー入力時というイベントがあるので、これで任意のキー入力に対して特定のコントロールをアクティブにすることができます。
また、オプションに「Enterキー入力後の動作」があるので、これを変更するとExcelと似たような動作になります。
このオプションはパソコン（インストールされたACCESS）毎の設定をデフォルトから変えることになるので、環境ごとに設定が必要です。
リンゴ様
「取引先コード」に入力後、ほかの部分をクリックしても同様です・・・。
色々お力添え頂きありがとうございます。
ところで、これはお遊びですが
テーブル1『実テーブル』(実データ)🔑初期ID,🔑データKEY,属性,区分
テーブル2『仮テーブル』(基本空っぽ)🔑初期ID,🔑データKEY,属性,区分
クエリ1『実クエリ』(テーブル1の選択クエリ)
クエリ2『仮クエリ』(テーブル2の選択クエリ)
追加クエリ『実リストから仮テーブルへ』(テーブル1の追加クエリ)※実リストはそのまま。
抽出条件:テキストボックス1、テキストボックス2
削除クエリ『仮リストから削除』(テーブル2の削除クエリ)※実リストはそのまま。
抽出条件:テキストボックス3、テキストボックス4
更新クエリ『実テーブルと仮テーブルを内部結合』(テーブル1の更新クエリ)
抽出条件:なし,レコードの更新:テキストボックス5
テキストボックス1『初期ID、実リストから追加クエリへ』 (非連結):⬜⬜⬜
テキストボックス2『データKEY、実リストから追加クエリへ』(非連結):⬜⬜⬜
テキストボックス3『初期ID、仮リストから削除クエリへ』 (非連結):⬜⬜⬜
テキストボックス4『データKEY、仮リストから削除クエリへ』(非連結):⬜⬜⬜
コマンドボタン1『更新ボタン』テキストボックス5『新しい更新値』(非連結):⬜⬜⬜
リストボックス1『実リスト』(非連結) リストボックス2『仮リスト』(非連結)
値集合ソース:クエリ1 値集合ソース:クエリ2
例えば、行を選んで半角スペースキーを押すと、選択行の初期IDとデータKEYがテキストボックスに代入、追加クエリが実行されるように。実データが絞り込まれて、仮テーブルに追加されるので、仮リストの再クエリ。
更新クエリを実行すると、新しい区分値に更新。但し初期IDとデータKEYの組み合わせが同じものに限る。
単独主キーですがこんなのもあるみたいですよ。複合主キーに応用する事ができれば。
複数選択リストボックスで選択したレコードの印刷 - hatena chips
ちなみに、これはどうですか？
コマンドボタン『ほにゃらら』を押すと、区分が未定のときは検査完、検査完のときは未定になるように。
コメントありがとうございます。そうです。
”レコードを複数選択し、該当フィールドをまとめて更新したい”です。
１レコードずつ更新する仕組みで作られているのですが、利用者からめんどくさいからまとめて更新ができないかという相談があって改修しているのですが、1レコードずつ更新する仕組みも残したまままとめて更新できるように
別に非連結チェックボックスで選択して更新できるような仕組みを作っていたんです。
チェックする仕組みは参考URLで、できたのですが、データ初期IDが同じものだと一緒にチェックされてしまうのをなんとかすれば他はうまくいきそうなんです。
外部からは判断の難しい状況になっているようですね。
実際のファイルを見ないと原因究明は難しいかもしれません。
この掲示板の右カラムの一番下に「ファイル送信フォーム」があります。
そこからファイルを送信することができますので、
うまくいかない現状のファイルを送ってもらえたら、
原因がわかるかもしれません。
フォームは連結フォームでしょうか。非連結フォームでしょうか。
連結フォームなら、コマンドボタンのコントロールウィザードでレコード削除のマクロを作成すれば、
カレントレコードを削除できるはずです。
それでうまくいかないのなら、
フォームの構成、レコードソースのテーブル構成等、詳細な説明をしてください。
解決済みとのことですが、レポートの場合は、サブレポートとして埋め込むことになります。
マクロにも影響するかわからないけれど、エラーメッセージの表示設定はありになっていますか？
アクション クエリのメッセージを非表示にするには - Access - ヘルプの森