Access総合相談所 30
■ このスレッドは過去ログ倉庫に格納されています
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/ >>44 ODBC接続してる先はAccessなのか他のDBなのか不明 クエリーはAccessだからmdb開いたら見れるでしょ 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 解決策に心当たりがあれば教えてください。 >>46 VBAのコンパイルエラー mdb開いて非表示VBAを探しだして非表示解除してVBA修正する以外に方法は無いよ 少なくともVBAだからクエリーでは無いな すみません 金曜日にITが黙ってでofficeを64bitに置き換えてました... 32bit版に戻して解決 ほんとにすみませんでした >>48 Win64bit上でACCESS32bitを動かすのは問題ないですよ。 >>50 64bitにしたって書いてあるじゃん そしたらProgram Files (x86)参照しても何もないでしょ >>50 64bitにしたって書いてあるじゃん そしたらProgram Filesフォルダに入るから、Program Files (x86)参照しても何もないでしょ 二週間ごとに集計だしてレポートやフォームに表示するのってどうしたらいいですか? selectするときに日付を数値にして14で割って四捨五入した値を項目に加え、それでgroup byして出たものを表示すればいい ACCESSってフォーム使うならVBAで更新いれられるけどそうじゃないと開いたときのままのレコードが表示されつづけるから不便じゃない? 集計クエリとか閉じたり開いたりしなきゃいけないよね >>55 選択クエリを作る、作ったクエリを元にフォームやレポートを作る、です。 質問読み間違えた。2週間に1回集計するんじゃないのね、すまんすまん。 >>58 確かにそうも取れるよね こういうのはExcelでやったほうが早いと思うけどね ピボット使えばフィルタリングなんかも楽だし計算してでた結果を何も考えずに表示させられるし >>61 フォームで入力するので、そこにも表示させたいんですよね >>53 2週間毎にPCにAccess自動起動するタイマー設定する Accessは起動時の設定でレポート、フォーム表示させる様にしておく >>63 >>64 すみません、書き方が悪かったです テーブルにあるレコードの二週間ごとの合計値をだしたい、ということです 二週間を一単位として、日々加算していき次の二週間でまた一からはじめるということです 月初を起算日にします >>65 だから2週間毎の集計クエリを自動実行する様にPCにスケジューリングする 根本的にこの人は"タスク"と言う事が理解出来て無い様だな 2週間たって自動で自らAccessが起動かかる仕組みは中に実装出来ない >>62 DSumで期間指定して集計 対象データが更新されるたびにコントロールをRequeryで更新 >>69 二週間の期間指定ってどうするの? 対象データが更新されるたびってフォームじゃないとできなくない? >>70 VBAは最低必要になるな 再クエリだけでは無理 Excelで計算してACCESSに戻すしかなさそう ACCESSって基本的には計算や整理されたデータをいれとくだけのソフトだからねえ あれもこれもはできない Accessでって言ってるのにExcel使うなんて本末転倒 VBAで時間カウントするかPCタスク使うしか無いよ >>74 俺は>>61 ,69 だけど >>54 を前提に話しているよ タスクがどうとか言っているやつは知らん >>70 レポートは解決。後はフォームだけだろ? >>75 JOINでレコード数が掛け算で桁違いに増えるというわけでもないし、重くなる要素がないんだが 単に集計したのを表示・印刷するだけなのか集計結果をテーブルに保存するのか 何か後者前提で話してるヤツいるな フォームとレポートに出すだけなら開く時に都度集計でもよくね? >>65 >>54 で良さそうだよ。クエリで出来る。 2週間毎の集計クエリが出来たらそれを元にフォームなりレポートなり作れば簡単そう。 >>79 >>62 から明細を入力しつつ合計を確認したいという要望が読み取れるだろ? そもそもACCESSって集計や累計計算って苦手すぎるよね >>80 フォームに入力してボタンを押したらマクロでリフレッシュするようにすればいいだけ Me.Requery Me.Refresh でできる キー入力でイベント発生させてもいいけど入力途中でも集計されてしまうのを許容できるかによる フレンド限定マルチは、野良マルチのマッチング率下がるからやりたくないだけじゃね >>84 レコード増えたら全件で集計するとか激重じゃない? 便乗で、 年間の労働時間の合計を従業員ごとに集計するのはどうしたらいいですか? 集計フィールドにDSumだと激重ということみたいですが SELECT 従業員, Sum(労働時間) AS 2021年の労働時間 FROM テーブル WHERE 年=2021 GROUP BY 従業員 >>91 ありがとうございます レコード増えたら実行時には重くなるけど現実的な量では問題ないということですか? Sum(労働時間) 、について、労働時間:出勤時間−退勤時間 のフィールドをクエリに作っておくということですか? フォームに2021年の労働時間を表表示させておき 更新ボタンで再度実行するかたちですか? 最低単位が分なら SELECT 従業員, Sum(Datediff(n,出勤時間,退勤時間)) AS 2021年の労働時間 FROM テーブル WHERE 年=2021 GROUP BY 従業員 というか、仕様を公開しないとどういう項目があるのかすらわからないだろ 更新ボタンでもいいしフォームのどこかをダブルクリックしたら更新するでもいいし、それはマクロのプロシージャをどれにするかだけの話 自分がやりたいことを細かく書き出して、どれができてどれができないからこれを教えてほしいと言わないと何度も手間になるだけ >>94 一年間の変形労働時間制というものを採用していて 年間の労働時間というのが決まっています 日々の労働時間を入力していき、労働時間をその上限から引いていく ということをしたいです フォームで時間を入力したときに、残り時間は○時間だから休みをいれて調整しよう、とかの判断をしたいです 最初にあいまいな質問をして迷惑をおかけしました >>95 労働時間を入力しているなら>>91 でいいじゃん >>96 労働時間というのは始業開始時間と始業時間ということでその時間はクエリもしくは集計フィールドでやってます >>95 時間を入力したら残り時間が計算されるようにする→Datediffで労働時間を求めてSumしたやつを上限から引けば残り時間が出る 調整の判断をしたい→誰が?何の基準で? 人間が勝手に判断するのならAccessと関係ないから勝手にどうぞ 自動で判断したいのならどういう基準でどう判断したいのか、それによってSQLで済むのかVBAを使う必要があるのかが変わってくる まだあいまいすぎる 本当に細かいところまで全部規格を詰めろ コミュニケーション能力がないと人に教わることもできないという実例 マウントを取ろうと上からの物言いをするので何も伝えたり教えたりすることができないという実例。 Access使うならVBAぐらい習得しとか無いと苦労する事になる クエリ(SQL文)で出来る範囲は有限だし 自分の中で漠然とこういうものが欲しいと願うだけで誰かが無料で適切なものを提供してくれると思ってんだろ 他人が考え出してくれたアイデアは掲示板では無料だからね 皆時間取って書き込みしてんだから一つ一つ精査して出来るか試してみれば良いのに 部分的に教えてもらって残りは自分で作るんじゃなくて、クエリ1〜2行だけで全部思ったように動くようなものをずばり教えてもらえることを夢見てんじゃないの まあまあ,うまく質問するのも時間が掛かるよ,ケンケンしないでフンワリ行きましょう. >>98 単純に考えて毎日出勤と退勤時間を入力していって その時に年間の上限の労働時間から引いた値を表示させたい それを目安にあと100時間しかないから休みをいれるか、とかの判断をするってことなんじゃないの? 俺はそういうのはExcelで入力、計算させて月単位とかでインポートしてる ACCESSで数値訂正すると合計がずれるから訂正はできないんだけどね >>107 そんなことはみんなわかってるよ 表示させたいのところはもう既出でできてるでしょ だからその判断は具体的に誰がどうするのって話 100時間固定ならそれはそれでできるし、プログラムで複雑な判断をするのか、もしくは人が判断するからその部分は作らなくていいのか、そういうところが全く情報がない 1.Formで毎日の出勤状況入力 2.ボタン押下で2週間毎(基準をいつにするか不明だが)に計算(クエリ使うかVBA)して一覧表示(社員毎) 3.それをレポート化 これぐらい体系立って考え無いとダメだで >>109 判断は誰がするのか?とか、そこが必要な部分について質問者は聞いてないんじゃない? 単に、2週間毎の集計をしたいと。 その先について、あなたが勝手に推測でしてもっと詰めろと、ひとりでいきりたってるようにしか見えないよ。 自分は、質問者の文面からは、超アナログに管理者なり労働者が今年はもう働きすぎだなあ、ちょっと調整するか、とか考えるレベルのことでいいと読み取れたけど。 >>110 2週間毎は関係ないと思うけど 同じ案件だったの? >>111 そもそも合計なんてフォームフッターでもレポートフッターでも標準機能だぞ? 何が分からないのか何を聞きたいんだかさっぱりなんだが? >>111 ,112 背景が見えないから最終的にどうしたいか見えないのが問題なんだよ まあ月初起算の2週間置き集計が出来ればOKでしょ。29日以降どうするのかとか謎はまだあった。 おさわがせしてすみません やりたいことを細かく書きます 運送業をしていて法的に運行管理というものが必要で画像のような規則になっています 改正があったのか二週間の合計と言っていたのは計算しなくてよくなったようです そのかわり15時間以上は週に二回、というカウントが必要です 上限が、 年間3516時間 月293時間(年に六ヶ月までは年間を超えない範囲で月320時間までよい) 毎日出退勤時間を入力して、これをオーバーしないように計算したい、オーバーしそうなときに残り時間をみて休みをいれたり早く帰ってもらってりする、ということです https://i.imgur.com/F6KYmdv.jpg >>116 技術的には普通にできるね 条件設定がいろいろあって手間がかかるけど それで、あなたはどこまでできて、何ができないから教えてほしいの? 全部丸投げでやらせようということ? まさかそれでできたものを製品として発注元の運送業者に売ったりしないよね? 運送業に携わってるはずなのに詳細を把握してなかったのは怪しいな 改正とか言ってとぼけてるけど これだけいろいろ条件が変わるんじゃ最初の質問に答えても無意味だったってことだね >>119 ザル法なんでみんな守ってないし(7割が違反しているらしい)コロコロ変わったり運輸支局で解釈違ったりするので把握するのが難しいんですよね >>118 テーブルと入力フォーム、レポートは作ってDsumで計算するようにしました 集計フィールドとクエリでの計算どちらもしてみましたが違いはわかりませんでした まだ一年分(20人程度なので一日20レコード程度、どんどんレコードは貯まるので激重になるんですよね)もないので問題はなさそうですが、レコードが増えると全レコードが対象になるのでとても使えなくなるときいたので、改善したいです >>122 じゃあこのSQLはできていて、それをもっと軽くしたいということね それなら今のSQL文を書いてもらわないと改善できないよね 細かいところ書きたくなければ大枠だけでも出してもらわないと ただそもそも改善する必要があるのかどうか レコード数の見積もりは増えたときにどの程度なの? あとはSQL文内にJOINを使っているかどうかで処理数が変わってくるのでそこがわからないと正しいことは言えない 一年間の集計でいいんだから古い期間のデータは過去テーブルに移動すれば 重さはいつも変らないじゃん WHEREでその年だけ選択すれば移動しなくてもたいして重くならないんじゃないの? >>123 SQLではなくクエリのフィールドに計算式をかきました >>124 なるほど、重くなってきたら過去のレコードだけを格納しておくテーブルに移動させるということですね >>125 そもそも移動させなくてもこれでいいんですかね 背景が出て来たね 要件定義しっかりしてまとめ直せば Accessだけ(ただしVBAとかは必要かも)で出来る内容だな まあ、受託開発かも知れないが施主にインタビューしっかりして情報全て出させ無いとちゃぶ台返しくらうからね 気を付けるこった 昔のRAM500MBみたいな環境じゃないんだから対象データは全部RAMに乗るしインデックスすら効果がわからない程度の改善しかできないだろう 今回ならDSUMやめてSUMしたのとJOINするぐらいか >>129 たしかにACCESSってファイルが20GBとかにならないから全部メモリに展開できるから遅くはならないのかもね レポートつくるときって基本的にテーブルじゃなくてクエリから作ったほうがいいの? SQLで2020年のレコードで絞り込むとき WHERE 年=2020とかにするんですよね? この年代の指定を非連結フィールドに入力した値にするにはどうしたらいいんですか? 非連結=2020 ですか? 手元にACCESSがないので検証できませんが出先で記述だけしておきたいです 年がテーブルのフィールド名、 text年が非連結のテキストボックスだとして、 select ・・・ where 年=text年; かな。 年が独立した数字フィールドって事は無さそうだけど。 >>136 基本的にクエリの計算フィールドが必要じゃない? 計算フィールドも内部的にはクエリであり、違うというのは屁理屈でしかない ベースはテーブルだけで良い 計算とかレポート側でもクエリ加工でも出来る >>140 後から加工することになるかもしれないからとりあえずクエリでレポート作ったほうがよくない? >>142 システム的にはレポートはテーブルを基本にする 実際はそこまで気にして使ってる層は無いのでクエリでも良い ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる