X

Access総合相談所 30

■ このスレッドは過去ログ倉庫に格納されています
2021/04/07(水) 12:33:01.06
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ 質問内容は具体的に書いてください。
　　業務上の守秘義務も大事ですが、貴方の所属組織を特定できるほど、特異な業務・システムは滅多にありません。
　作りたいものの内容を隠しすぎないようにし、列名、データ値を適当に変更して例示するなどしましょう。
★ 事前にGoogle等で調べられる範囲は調べてください。
★ 完全初心者はまず、新規作成テンプレから「NorthWind」を開いて、一通り触ってみてください。ACCESSの概念を理解する
もっとも簡単な方法です。
★ お金の管理でシステム設計ミスが会社経営に重大な支障が予見される場合は、パッケージソフトに誘導する場合があります。
格安なソフトもあるので設計に取りかかってから悩む前に、市場調査も行なってください。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
　　ギブアンドテイクで情報を共有しましょう。
▼━初心者用質問テンプレ ━━━━━━━━━━━━━━━━━
【Windows】 7, 8,10 【Access】 365,2013,2016,2019
【作りたいものの業務分野】
販売管理,買掛管理,営業予算管理,営業実績管理,生産管理,財務管理,労務管理,学術研究統計,文字格納を主体としたDB,その他（）
【あなたのスキル】
LV1:完全初心者,
LV2:ACCESSの基本要素（テーブルやクエリーなど）の役割を知っている
LV3:VBAが打てる
【どのオブジェクトに関する質問か】
テーブル,クエリー,フォーム,レポート,サブフォーム（サブレポート）,リレーション,VBA
【やりたいこと】
（質問によっては各テーブル名と列名を例示）
（クエリーの場合は、左上の「表示」を押し”SQLビュー”に変更して表示される”SQL文”を貼り付けると回答者がわかりやすい）
(得たい出力結果や挙動)
【エラーメッセージに関する質問】
・エラーメッセージの内容　・windowsは32bit版か64bit版か
前スレ
Access総合相談所 29
https://mevius.5ch.net/test/read.cg/bsoft/1569236545/
2021/04/13(火) 13:57:02.99
>>44
ODBC接続してる先はAccessなのか他のDBなのか不明
クエリーはAccessだからmdb開いたら見れるでしょ
2021/04/13(火) 15:56:53.07
Windows10 Pro (64bit) Access 2016 (32bit)
の環境です。昔作成したAccessのファイルを開いたところ、
非表示モジュール内でコンパイルエラーが発生しました。
「通常このエラーは、コードがこのアプリケーションのバージョン、プ
ラットフs (x86)\Common Files\Microsoft Shared\VBA\VBE6EXT.ODB#Microso
(表示されたものすべてです)」
のエラーが表示されて使えなくなってしまいました。
調べたところ、参照エラーとのことですが、
ファイルは
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB
にあり、レジストリの
Computer\HKEY_CLASSES_ROOT\TypeLib\{0002E157-0000-0000-C000-000000000046}\5.3\0\Win32
の値も
C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX86\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB
と一致しております。
vb
解決策に心当たりがあれば教えてください。
2021/04/13(火) 17:28:30.17
>>46
VBAのコンパイルエラー
mdb開いて非表示VBAを探しだして非表示解除してVBA修正する以外に方法は無いよ
少なくともVBAだからクエリーでは無いな
2021/04/13(火) 17:42:34.22
>>46
ああ64bit OSで32bit版動かそうとしてるのか
そりゃ無理じゃね

https://answers.microsoft.com/ja-jp/msoffice/forum/msoffice_access-mso_winother-mso_2010/access%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB32bit/88f966d6-1713-48e0-89de-d3b827f29a7a

コンパイルエラーになるのは当然じゃ
4946
垢版 |
2021/04/13(火) 18:15:01.04
すみません
金曜日にITが黙ってでofficeを64bitに置き換えてました...
32bit版に戻して解決

ほんとにすみませんでした
2021/04/13(火) 18:27:16.79
>>48
Win64bit上でACCESS32bitを動かすのは問題ないですよ。
2021/04/13(火) 20:59:14.60
>>50
64bitにしたって書いてあるじゃん
そしたらProgram Files (x86)参照しても何もないでしょ
2021/04/13(火) 20:59:29.99
>>50
64bitにしたって書いてあるじゃん
そしたらProgram Filesフォルダに入るから、Program Files (x86)参照しても何もないでしょ
2021/04/14(水) 01:28:00.97
二週間ごとに集計だしてレポートやフォームに表示するのってどうしたらいいですか？
2021/04/14(水) 06:12:48.12
selectするときに日付を数値にして14で割って四捨五入した値を項目に加え、それでgroup byして出たものを表示すればいい
2021/04/14(水) 06:32:03.63
>>54
SQL書くってことですか？
2021/04/14(水) 06:39:01.58
ACCESSってフォーム使うならVBAで更新いれられるけどそうじゃないと開いたときのままのレコードが表示されつづけるから不便じゃない？
集計クエリとか閉じたり開いたりしなきゃいけないよね
2021/04/14(水) 06:55:22.53
>>55
選択クエリを作る、作ったクエリを元にフォームやレポートを作る、です。
2021/04/14(水) 06:59:04.36
質問読み間違えた。2週間に1回集計するんじゃないのね、すまんすまん。
2021/04/14(水) 07:19:35.27
>>58
>>54
これじゃだめってことですか？
2021/04/14(水) 07:24:34.41
>>58
確かにそうも取れるよね

こういうのはExcelでやったほうが早いと思うけどね
ピボット使えばフィルタリングなんかも楽だし計算してでた結果を何も考えずに表示させられるし
2021/04/14(水) 07:38:55.08
>>59
レポートのグループヘッダー使えばいい
2021/04/14(水) 08:50:29.51
>>61
フォームで入力するので、そこにも表示させたいんですよね
2021/04/14(水) 10:23:10.55
>>53
2週間毎にPCにAccess自動起動するタイマー設定する
Accessは起動時の設定でレポート、フォーム表示させる様にしておく
2021/04/14(水) 10:24:21.72
単にAccess自動起動の問題
2021/04/14(水) 12:27:03.16
>>63
>>64
すみません、書き方が悪かったです
テーブルにあるレコードの二週間ごとの合計値をだしたい、ということです
二週間を一単位として、日々加算していき次の二週間でまた一からはじめるということです
月初を起算日にします
2021/04/14(水) 12:36:01.09
>>65
だから2週間毎の集計クエリを自動実行する様にPCにスケジューリングする
2021/04/14(水) 12:46:02.09
根本的にこの人は"タスク"と言う事が理解出来て無い様だな
2週間たって自動で自らAccessが起動かかる仕組みは中に実装出来ない
2021/04/14(水) 13:05:14.85
>>56
再クエリーってコマンドあったはず
2021/04/14(水) 13:13:06.58
>>62
DSumで期間指定して集計
対象データが更新されるたびにコントロールをRequeryで更新
2021/04/14(水) 13:58:45.68
>>69
二週間の期間指定ってどうするの？
対象データが更新されるたびってフォームじゃないとできなくない？
2021/04/14(水) 14:35:56.09
>>70
VBAは最低必要になるな
再クエリだけでは無理
2021/04/14(水) 14:44:28.71
Excelで計算してACCESSに戻すしかなさそう
ACCESSって基本的には計算や整理されたデータをいれとくだけのソフトだからねえ
あれもこれもはできない
2021/04/14(水) 15:51:57.02
Accessでって言ってるのにExcel使うなんて本末転倒
VBAで時間カウントするかPCタスク使うしか無いよ
2021/04/14(水) 17:54:17.63
だからさあ、>>54じゃなんでだめなの？
2021/04/14(水) 18:02:35.43
>>74
激重になりそう
2021/04/14(水) 18:30:31.30
>>74
俺は>>61,69 だけど >>54を前提に話しているよ

タスクがどうとか言っているやつは知らん

>>70
レポートは解決。後はフォームだけだろ？
2021/04/14(水) 18:56:01.26
>>75
JOINでレコード数が掛け算で桁違いに増えるというわけでもないし、重くなる要素がないんだが
2021/04/14(水) 19:01:54.08
単に集計したのを表示・印刷するだけなのか集計結果をテーブルに保存するのか

何か後者前提で話してるヤツいるな
フォームとレポートに出すだけなら開く時に都度集計でもよくね？
2021/04/14(水) 19:07:24.03
>>65
>>54　で良さそうだよ。クエリで出来る。
2週間毎の集計クエリが出来たらそれを元にフォームなりレポートなり作れば簡単そう。
2021/04/14(水) 19:15:02.01
>>79
>>62から明細を入力しつつ合計を確認したいという要望が読み取れるだろ？
2021/04/14(水) 19:51:47.84
そもそもACCESSって集計や累計計算って苦手すぎるよね
2021/04/14(水) 19:54:57.86
超得意分野ですが
2021/04/14(水) 19:56:53.45
>>81
おバカ自慢は要らない
2021/04/14(水) 20:01:02.26
>>80
フォームに入力してボタンを押したらマクロでリフレッシュするようにすればいいだけ
Me.Requery
Me.Refresh
でできる
キー入力でイベント発生させてもいいけど入力途中でも集計されてしまうのを許容できるかによる
2021/04/14(水) 20:29:06.80
フレンド限定マルチは、野良マルチのマッチング率下がるからやりたくないだけじゃね
2021/04/14(水) 20:29:31.52
誤爆なり
2021/04/14(水) 20:44:56.31
ちょっと何言ってんのかわかんなかったから焦ったわ
2021/04/14(水) 20:59:04.40
>>84
レコード増えたら全件で集計するとか激重じゃない？
2021/04/14(水) 21:15:36.01
>>88
数百万件レベルだと秒単位でかかるかもな
2021/04/14(水) 21:32:26.31
便乗で、
年間の労働時間の合計を従業員ごとに集計するのはどうしたらいいですか？
集計フィールドにDSumだと激重ということみたいですが
2021/04/14(水) 21:46:45.48
SELECT 従業員, Sum(労働時間) AS 2021年の労働時間 FROM テーブル WHERE 年=2021 GROUP BY 従業員
2021/04/14(水) 21:50:32.55
早いなSQL職人
2021/04/14(水) 22:07:48.23
>>91
ありがとうございます
レコード増えたら実行時には重くなるけど現実的な量では問題ないということですか？

Sum(労働時間) 、について、労働時間:出勤時間−退勤時間
のフィールドをクエリに作っておくということですか？

フォームに2021年の労働時間を表表示させておき
更新ボタンで再度実行するかたちですか？
2021/04/14(水) 23:15:07.77
最低単位が分なら
SELECT 従業員, Sum(Datediff(n,出勤時間,退勤時間)) AS 2021年の労働時間 FROM テーブル WHERE 年=2021 GROUP BY 従業員

というか、仕様を公開しないとどういう項目があるのかすらわからないだろ
更新ボタンでもいいしフォームのどこかをダブルクリックしたら更新するでもいいし、それはマクロのプロシージャをどれにするかだけの話
自分がやりたいことを細かく書き出して、どれができてどれができないからこれを教えてほしいと言わないと何度も手間になるだけ
2021/04/14(水) 23:49:07.36
>>94
一年間の変形労働時間制というものを採用していて
年間の労働時間というのが決まっています
日々の労働時間を入力していき、労働時間をその上限から引いていく
ということをしたいです

フォームで時間を入力したときに、残り時間は○時間だから休みをいれて調整しよう、とかの判断をしたいです

最初にあいまいな質問をして迷惑をおかけしました
2021/04/15(木) 01:41:48.88
>>95
労働時間を入力しているなら>>91でいいじゃん
2021/04/15(木) 01:53:12.54
>>96
労働時間というのは始業開始時間と始業時間ということでその時間はクエリもしくは集計フィールドでやってます
2021/04/15(木) 07:02:29.66
>>95
時間を入力したら残り時間が計算されるようにする→Datediffで労働時間を求めてSumしたやつを上限から引けば残り時間が出る

調整の判断をしたい→誰が？何の基準で？
人間が勝手に判断するのならAccessと関係ないから勝手にどうぞ
自動で判断したいのならどういう基準でどう判断したいのか、それによってSQLで済むのかVBAを使う必要があるのかが変わってくる

まだあいまいすぎる
本当に細かいところまで全部規格を詰めろ
2021/04/15(木) 07:07:41.65
いえ、もう結構です
2021/04/15(木) 07:31:26.32
コミュニケーション能力がないと人に教わることもできないという実例
2021/04/15(木) 12:51:56.58
マウントを取ろうと上からの物言いをするので何も伝えたり教えたりすることができないという実例。
2021/04/15(木) 13:15:41.07
Access使うならVBAぐらい習得しとか無いと苦労する事になる
クエリ(SQL文)で出来る範囲は有限だし
2021/04/15(木) 13:25:59.45
自分の中で漠然とこういうものが欲しいと願うだけで誰かが無料で適切なものを提供してくれると思ってんだろ
2021/04/15(木) 13:36:00.68
他人が考え出してくれたアイデアは掲示板では無料だからね
皆時間取って書き込みしてんだから一つ一つ精査して出来るか試してみれば良いのに
2021/04/15(木) 14:21:01.19
部分的に教えてもらって残りは自分で作るんじゃなくて、クエリ1〜2行だけで全部思ったように動くようなものをずばり教えてもらえることを夢見てんじゃないの
2021/04/15(木) 14:23:12.83
まあまあ,うまく質問するのも時間が掛かるよ,ケンケンしないでフンワリ行きましょう.
2021/04/15(木) 16:41:01.99
>>98
単純に考えて毎日出勤と退勤時間を入力していって
その時に年間の上限の労働時間から引いた値を表示させたい
それを目安にあと100時間しかないから休みをいれるか、とかの判断をするってことなんじゃないの？
2021/04/15(木) 16:49:00.66
俺はそういうのはExcelで入力、計算させて月単位とかでインポートしてる
ACCESSで数値訂正すると合計がずれるから訂正はできないんだけどね
2021/04/15(木) 17:24:10.81
>>107
そんなことはみんなわかってるよ
表示させたいのところはもう既出でできてるでしょ
だからその判断は具体的に誰がどうするのって話
100時間固定ならそれはそれでできるし、プログラムで複雑な判断をするのか、もしくは人が判断するからその部分は作らなくていいのか、そういうところが全く情報がない
2021/04/15(木) 17:25:18.63
1.Formで毎日の出勤状況入力

2.ボタン押下で2週間毎(基準をいつにするか不明だが)に計算(クエリ使うかVBA)して一覧表示(社員毎)

3.それをレポート化

これぐらい体系立って考え無いとダメだで
2021/04/15(木) 17:58:34.58
>>109
判断は誰がするのか？とか、そこが必要な部分について質問者は聞いてないんじゃない？

単に、2週間毎の集計をしたいと。
その先について、あなたが勝手に推測でしてもっと詰めろと、ひとりでいきりたってるようにしか見えないよ。

自分は、質問者の文面からは、超アナログに管理者なり労働者が今年はもう働きすぎだなあ、ちょっと調整するか、とか考えるレベルのことでいいと読み取れたけど。
2021/04/15(木) 17:59:32.89
>>110
2週間毎は関係ないと思うけど
同じ案件だったの？
2021/04/15(木) 18:03:13.59
>>111
そもそも合計なんてフォームフッターでもレポートフッターでも標準機能だぞ？
何が分からないのか何を聞きたいんだかさっぱりなんだが？
2021/04/15(木) 18:04:16.80
>>111,112
背景が見えないから最終的にどうしたいか見えないのが問題なんだよ
2021/04/15(木) 18:34:23.16
まあ月初起算の2週間置き集計が出来ればOKでしょ。29日以降どうするのかとか謎はまだあった。
2021/04/15(木) 19:23:06.11
おさわがせしてすみません
やりたいことを細かく書きます

運送業をしていて法的に運行管理というものが必要で画像のような規則になっています

改正があったのか二週間の合計と言っていたのは計算しなくてよくなったようです
そのかわり15時間以上は週に二回、というカウントが必要です

上限が、
年間3516時間
月293時間（年に六ヶ月までは年間を超えない範囲で月320時間までよい）

毎日出退勤時間を入力して、これをオーバーしないように計算したい、オーバーしそうなときに残り時間をみて休みをいれたり早く帰ってもらってりする、ということです

https://i.imgur.com/F6KYmdv.jpg
2021/04/15(木) 19:27:01.93
>>111
>>95
2021/04/15(木) 19:39:57.76
>>116
技術的には普通にできるね
条件設定がいろいろあって手間がかかるけど
それで、あなたはどこまでできて、何ができないから教えてほしいの？
全部丸投げでやらせようということ？
まさかそれでできたものを製品として発注元の運送業者に売ったりしないよね？
2021/04/15(木) 19:50:29.32
運送業に携わってるはずなのに詳細を把握してなかったのは怪しいな
改正とか言ってとぼけてるけど
2021/04/15(木) 19:52:12.90
これだけいろいろ条件が変わるんじゃ最初の質問に答えても無意味だったってことだね
2021/04/15(木) 20:08:25.68
おや、この流れは?
2021/04/15(木) 20:20:31.40
>>119
ザル法なんでみんな守ってないし（7割が違反しているらしい）コロコロ変わったり運輸支局で解釈違ったりするので把握するのが難しいんですよね

>>118
テーブルと入力フォーム、レポートは作ってDsumで計算するようにしました
集計フィールドとクエリでの計算どちらもしてみましたが違いはわかりませんでした
まだ一年分（20人程度なので一日20レコード程度、どんどんレコードは貯まるので激重になるんですよね）もないので問題はなさそうですが、レコードが増えると全レコードが対象になるのでとても使えなくなるときいたので、改善したいです
2021/04/15(木) 20:29:54.49
>>122
じゃあこのSQLはできていて、それをもっと軽くしたいということね
それなら今のSQL文を書いてもらわないと改善できないよね
細かいところ書きたくなければ大枠だけでも出してもらわないと
ただそもそも改善する必要があるのかどうか
レコード数の見積もりは増えたときにどの程度なの？
あとはSQL文内にJOINを使っているかどうかで処理数が変わってくるのでそこがわからないと正しいことは言えない
2021/04/15(木) 20:33:14.17
一年間の集計でいいんだから古い期間のデータは過去テーブルに移動すれば
重さはいつも変らないじゃん
2021/04/15(木) 20:49:37.19
WHEREでその年だけ選択すれば移動しなくてもたいして重くならないんじゃないの？
2021/04/15(木) 21:18:09.52
>>123
SQLではなくクエリのフィールドに計算式をかきました
>>124
なるほど、重くなってきたら過去のレコードだけを格納しておくテーブルに移動させるということですね
>>125
そもそも移動させなくてもこれでいいんですかね
2021/04/15(木) 21:26:21.00
だからそもそも重くなるほど人いるのかよ
2021/04/15(木) 21:49:23.84
背景が出て来たね
要件定義しっかりしてまとめ直せば
Accessだけ(ただしVBAとかは必要かも)で出来る内容だな
まあ、受託開発かも知れないが施主にインタビューしっかりして情報全て出させ無いとちゃぶ台返しくらうからね
気を付けるこった
2021/04/16(金) 14:00:50.87
昔のRAM500MBみたいな環境じゃないんだから対象データは全部RAMに乗るしインデックスすら効果がわからない程度の改善しかできないだろう
今回ならDSUMやめてSUMしたのとJOINするぐらいか
2021/04/16(金) 17:27:53.93
>>129
たしかにACCESSってファイルが20GBとかにならないから全部メモリに展開できるから遅くはならないのかもね
2021/04/17(土) 01:43:00.98
レポートつくるときって基本的にテーブルじゃなくてクエリから作ったほうがいいの？
2021/04/17(土) 02:21:03.65
SQLで2020年のレコードで絞り込むとき
WHERE 年＝2020とかにするんですよね？
この年代の指定を非連結フィールドに入力した値にするにはどうしたらいいんですか？
非連結＝2020 ですか？
手元にACCESSがないので検証できませんが出先で記述だけしておきたいです
2021/04/17(土) 05:59:17.62
年がテーブルのフィールド名、
text年が非連結のテキストボックスだとして、
select ・・・ where 年=text年;
かな。
年が独立した数字フィールドって事は無さそうだけど。
2021/04/17(土) 10:26:10.99
>>131
テーブル
2021/04/17(土) 15:02:03.62
>>134
じゃあクエリはいつ使うの？
2021/04/17(土) 15:12:17.16
テーブルデータそのもの全部では事足りないとき
2021/04/17(土) 15:26:24.36
>>136
基本的にクエリの計算フィールドが必要じゃない？
2021/04/17(土) 15:30:44.34
レポートの計算フィールドでいいじゃん
2021/04/17(土) 15:45:00.99
計算フィールドも内部的にはクエリであり、違うというのは屁理屈でしかない
2021/04/17(土) 16:08:25.38
>>135
データ加工
2021/04/17(土) 16:10:01.12
ベースはテーブルだけで良い
計算とかレポート側でもクエリ加工でも出来る
2021/04/17(土) 16:18:28.50
>>140
後から加工することになるかもしれないからとりあえずクエリでレポート作ったほうがよくない？
2021/04/17(土) 16:19:18.99
好きにしろよw
2021/04/17(土) 16:23:22.58
>>142
システム的にはレポートはテーブルを基本にする
実際はそこまで気にして使ってる層は無いのでクエリでも良い
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況