Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ >>58
ただリンクするだけでいいならどのデータソースでも同じですよ。
複数の作業時の排他処理を書くのが結構面倒くさいので、事務員雇うのであればやっぱりAccessで組むことはお勧めしません。
そこらへんのロジック込みでやると構築に1ヶ月くらいはかかります。 小さい事務所でAccess、FileMakerとかでシステム化してる所多いが、Access、FileMaker使いこなせる人をそれなりに用意しないと後々困るよ
事務員の片手間で出来る様なモノでは無い 重くなる計算式が多いとき、保持させることがあると思います
再計算させるときは、どこかのフィールドに何か入力されたときに再度計算するようにVBAでつくればいいんですか？
ちなみに重い計算とはどのようなものでしょうか？
勤務時間を管理するとき
大量の勤務レコードから従業員ごとに、年ごと月ごとなのどの総計や、法定労働時間を超えていないかのチェックをする、程度だと非連結で都度計算で十分でしょうか？ >>65
FOMEの非連結に計算させるのか?
クエリーで計算した結果を中間テーブルで作成する、とか考え無いのかな?
MDB壊れたら終わりやで >>65
集計クエリーかけてテーブルに保存します。
あとは、もう一回集計したものテーブルをクエリーかけて、この列が何とか以上なら「多い」と表示せよ、とか
レポートやフォームの条件書式で色付けるとか、お好きにどうぞ。
集計のやり直しをしたい場合は
201810の全部をいったん削除して、
もう一回201810の全部を追加する
みたいなプログラミングをします。
もちろん従業員決め打ちでやってもかまいません。 >>67
そういう説明してもクエリーの活用をしないユーザーには多分想像出来ないと思うよ
VBAとFOMEの組み合わせでやってる可能性高いので発想がVB6プログラマーと変わらないと思われる
クエリーを活用するのがAccessの重要スキルって事が理解出来ていない様に思う
こういうユーザーはFileMakerとかに流れるパターン >>65
あと、その用途なら単に
excelからビボットテーブルのデータソースとしてテーブルかクエリーを指定してクロス集計させたほうが
幸せになれます。 >>68
sqlで結構なことできまっせ、が基本だよね。sqlは一応共通言語なので覚えて損はないし。
accessはまだしも、なんでexcelでvba書くのか意味分からん。
頼むから取引先、vba付きexcel書式を送らないで欲しい。vbaでパソコン破壊とか、普通にできちゃうし。 >>67
1万レコードのうち数個を修正したときも
クエリをやり直してテーブルに保存しなおすってことになるんですか？
非連結でやるのは、単価×個数、請求書の総計など簡単なものだけなんでしょうか？ >>71
おれも探してしまった 新しい仕様なのか？と >>71,73
FORMだったわすまん
>>72
1レコード変わったら集計値変わるでしょ
だから集計やり直しの為にクエリーもやり直し >>72
究極的に言うと「やってみれば」なんですよ。
このフローが遅いな、と思ったら違う手法を試せばよい。
しかし売り上げ請求とか、給与計算など、ミスが信用に関わる案件にはいきなり手を出さない方がいいです。 AccessをVBの代わりに使うのは問題無いがExcelは代わりにはならんな
帳票化も面倒だし
グラフ表示ぐらいしかメリット感じられない 【 システム環境 】 Windows10, Access2010
ID, name, 日付, 昼飯
2, 山田, 2018/05/03, うどん
3, 山田, 2018/07/08, そば
4, 鈴木, 2018/01/03, ラーメン
5, 鈴木, 2018/10/08, カレー
6, 鈴木, 2018/02/05, 牛どん
↓
ID, name, 日付, 昼飯
3, 山田, 2018/07/08, そば
5, 鈴木, 2018/10/08, カレー
人ごとに最新の日付の昼飯を抽出するにはどうしたらいいのでしょうか
SELECT [T1].name, Max([T1].日付)
FROM T1
GROUP BY [T1].name;
ここから先に奨めません >>74
非連結で計算するよりクエリのほうがはやいんですか？
レコード追加、削除、修正のたびに毎回すべてをやりなおすのは遅くないですか？
レコードに変更があったらそのたびにVBAでクエリやり直すんですよね？ >>62
商奉行とかってたいてい
https://i.imgur.com/EiRVBDQ.jpg
↑こういったUIですけど古臭いというか
ごちゃごちゃしていて入力し辛くないですか？
視点も操作もあちこちに移動しなければなりませんよね
伝票単位が基本ですが
伝票という概念がない（すべての売上が1レコード1売上になるので伝票が不要）業種は面倒なだけですよね
そもそも伝票自体紙ベースの名残なので旧態依然という感じもします >>77
max（昼飯）
マックスむらい的な。
ただし、1日に2回、昼飯を食っていないものとする。
ちなみに単なるレコードidを集合に含めるのは得策ではない。
max(id)を加えてもいいけど。 >>78
めんどくさいやつだな。絡むなよ。
いいから、ダミーデータでやってみてから文句言え。
プロが作ったERPのデータベース構造見たことある？
たいていは伝票登録のトランザクションの中で集計用テーブルに同時更新（または追加）を埋め込んでる。
それがスタンダードだけど、小規模事業者なら1ヶ月のレコードなどたかが知れてるので、ほぼvbaがいらない年月ごと消して埋め直して、を提示しただけ。 >>79
これも愚問。それを言ったら、簿記は全ての金の動きが1件1伝票じゃ。
仕入れで、小規模なものなら親子関係をもたない構造にしてもいいけど
売上で親子関係を結ばないのは普通有り得ない。
工事費、材料費で一伝票（あるいは見積書）を作成するわけで、明細がないドンブリ勘定で商売してるわけではないでしょ？ >>82
うちは、
1受注1売上1レコードです
2018/10/13 業務A 20000円
2018/10/13 業務B 20000
2018/10/14 業務A 30000
といった感じです
一つの受注に項目が2つあることはありません
なので伝票テーブルはつくっていません 販売系の概念だから業種によっては伝票に違和感あるひともいるんじゃない？
運送会社の事務方やってたときは伝票Tなかったな
一回の運行いくらだから、複数注文ってのが事実上ないからね
無駄なテーブルが介在することになるし
売上Tに運行内容と売上内容が直接記録されていく感じ
請求書はそのレコードを明細欄に並べてた >>78
少なくともAccessではクエリーの方が速い Accessの有意義なメリットがクエリーを視覚的に作れる部分だから
FileMakerなんかSQL文をベタ書きして実行する仕組みしか無いのでデータ加工の面倒な事
個人的にはFileMakerがクエリーを視覚的に作れたら最強だと思うがライセンス料金高いクセに、そこがクソ >>88
where条件は?
日付=MAX(T1.[日付]) >>88
間違えた
日付=MAX([T1].日付) >>88
ごめん、嘘こいた。
SELECT 名前,日付,昼飯
FROM テーブル1 INNER JOIN (
SELECT [テーブル1].名前 AS name2 ,Max([テーブル1].日付) AS 最新日付
FROM テーブル1
GROUP BY [テーブル1].名前) A ON テーブル1.日付=A.最新日付 AND テーブル1.名前=A.name2
これで合うか。 >>91
inner joinまで含めてSQL文手打ちするのか?
クエリー覚えさせた方が速いだろ >>92 そうだね、最近サーバのビューやストアドに
長々手打ちするので、慣れてしまったけど、
もう少し前の自分なら 集計クエリーで一旦保存して
それを内部結合させる二段構えにするかな。 accessは今は全く使えません
もし私の希望の作動ができるのであれば、勉強したいと思います
PC内と当該フォルダ以下にある全動画ファイルのアドレスを取得し、
そのファイルを一つずつ順番に外部動画ソフト(MPC-BE)にコマンドライン付きで投げ、
MPC-BEが吐いた静止画ファイルを、その動画ファイルと関連付けしデータベース化
クエリで抽出したデータから、ファイルと関連付けされてる静止画をリスト表示
静止画をクリックすると関連付けされたファイルをMPC-BEに投げて再生する
やりたいことは動画ファイル管理ソフトの範疇なのですが、世にある動画ファイル管理ソフトがうまく使えなかったり、作動しなかったり、帯に短し〜だったりで
自分なりのものを作ろうと思うのですが、CやC#より、外部ソフト使ってこっちのほうが簡単かなぁ？と思うのです
コレができるなら、いろんな情報をデータベースに登録して、動画用鯖の使い勝手が凄く増すのですが、
こんな事は可能でしょうか？ >>94 可能。便利かどうかは定かではない。
データベースモデルとしては図書館の検索システムとか、マスコミ御用達と言われている大宅宗一文庫（雑誌図書館）のデータベース、オンライン画像検索サービス。
設計構造よりも引っ掛けるキーワードをいかに充実させるかにかかってるんじゃないかな。 >>94
基本的には可能
コマンドラインで同期実行できるアプリなら楽
非同期実行されてしまうなら面倒
外部API公開しているなら超楽 >>95
>>96
どうもありがとうございます
プレーヤー側の操作はVBAでもできそうなので、どうにかなりそうです
ありがとうございました
勉強してみます >>86
10万レコードあるテーブルで計算が必要なときには
1レコード修正、追加するたびにクエリを作り直す処理にするものなんですか？ >>98
クエリーを作り直す訳無い
クエリーを実行し直す、と言う事 >>98
お前さんはレコード修正、追加と
集計結果の編集レポートを同列で話してるので解答者とは話がかみ合わない
FORMでレコードメンテナンスするのと帳票はタイミング違うだろ >>100
例えば勤怠記録をつけるとき
今日の分を入力するフォームに今月の労働時間など各種合計を表示させるのは非連結でやるんですか？
別途一覧表示などのレポートをつくるときがクエリなんでしょうか？
請求書の明細欄の合計なども非連結で
過去の請求書一覧を表示させるときなどに消費税や年間合計などを表示させるときにクエリなんでしょうか？ >>101
用途次第ですね。退勤記録を、あたかもタイムカードを見ているかのように
一人ずつ表示していきたい、なおかつ集計も見たいというなら、サブフォームのフッターに合計突っ込んで、親フォームでは、そのフッターを参照する式を書きます。（ここら辺、昔からACCESSの挙動が変なのでちょっとコツが入りますが）
請求は、参照閲覧用としては上に同じですが、締めという概念が入ってくるので、最終的にはいくら請求したかというテーブルが１個必要になって来ます。 >>102
退勤記録は
https://i.imgur.com/DBuPHIo.jpg
https://i.imgur.com/H8jxEhA.png
こういった感じで、月ごと日ごと従業員ごと、のような感じで表示させたいです
それぞれその日までの通算時間などを表示させて、です
このような場合はどのような設計がいいでしょうか？
請求書に関しては、売上テーブルから月末に対象となるものを駐出してそれを明細欄には表示させ
非連結で合計請求書や消費税を計算するつもりですが、まずいですか？
別途用意するテーブルとはどのようなものになるのでしょうか？ >>103 まず請求。普通の売り上げ管理システムには
締め作業があります。
この操作によって、伝票の修正禁止フラグを立てると同時に
締め期間ごとの合計金額と消費税計算が請求テーブルに
書きこまれます。「確かにこの金額請求しましたよ」の記録で、
その後の処理も作るとしたら回収管理につながります。
私もこの手のシステムの設計のお約束を全て知ってるわけ
じゃないけど、基本的にはこの手のシステムは「冗長的な記録」
（参照で済みそうなことの記録）をあえて行っている、と覚えてください。
次に退勤ですが、やれないことはないけど開発時間の浪費が
懸念されます。たとえば、マックス株式会社のタイムロボという
タイムレコーダーは10万円前後で、よくできた退勤管理ソフトも
ついてきます。
どうしても内製にこだわるなら、私ならEXCELにデータソースリンク
を作って、ピボットでクロス集計かける。 >>104
フラグで制御するよりテーブル分けろよ
締めた時点で帳票、集計画面用テーブル作れば良いだけ
リアルタイム操作用テーブルはFORMとペアで専用で用意 画像でいうところの請求金額や、各項目の数量×単価の金額のフィールドって非連結でやってたけどこれって間違い？
正しくはどうやればいいんでしょうか？
これは末締めじゃなくて直接入力みたいだけど
取引先と日付指定して該当のレコードを売上テーブルからひっぱってくるようなときの計算です
https://i.imgur.com/hx6I9f2.png >>106
テーブルに項目として計算結果持つ方法有る >>106
俺も非連結でやってたけどここみてたらおかしいのかな？と思ってきた
教科書的にはどうやるの？ >>105
標準的な設計ってそっちだっけ？
売伝のコピー作るってことでしょ。
私はあまり責任の重くない買掛だけ作ったときに（仕入先の請求書のほうが基本的に正しいから）、月締め後は直接仕入れ伝票に「もう弄るな」フラグ仕込んでるけど。 >>108
絶対に小数点以下が出ないのであれば
非連結でもいいんじゃないかな。
世の中、単価1.2円みたいな業種もあるので、この時は丸め計算の結果は登録しておく。
あと、食い物取引の軽減税率対応のシステムは明細単位で消費税類計算するロジックを採用してるのが多い。
レコード登録のもう一つのメリットはsum（数×単価）を毎回かけなくていいこと。今時のpcで体感差は出ないが。 >>109
物理的に分けた方が間違い起こしにくい
フラグ判定だと、バグでフラグ変わったら死ぬぞ 結局、末締請求書などをつくるシステムをつくるときは
全部クエリで計算してその結果をレポートに表示するようにしたほうがいいんですか？
それとも請求書を確定させたタイミングで
別テーブルに合計金額などを格納するレコードを作成して
idで紐づけたほうがいいんでしょうか？
（各明細の単価×個数などは非連結として）
よくわからなくなりました >>42
グラス片手にデータベース設計販売管理編とか読むといいかも >>112
どういう設計(システム的に)って話
これは経験しないと分からない >>114
あれ、いい本だよね。この本と、webサイトのT’s wareさんには大変
お世話になってる。 >>118
ね。平易で読みやすい。
そのサイト知らなかった。見てみる。 accdbを複数ユーザーで共有して使っています
フォームとデータを分離する必要性を全く感じません
ベンダってのはバカばかりなのでしょうか？ >>121
釣りですか。まあ、お好きにしてください。
なぜベンダー？ベンダーがACCESSで納品するのってレアケースですよ。
NASとかに置いて各PCから多重に開くことができる、割と珍しい作り
なので運用局面では支障がないかもしれません。
ただ、ちょっとフォームやレポートのここを直したいな、レポート
追加したいなって時に「はーい、全員閉じてー」って言わないと
保存できなかったはず。 >>123
わざわざライセンス払う必要無いDBあるからね SQL Serverだとサーバー買う必要があるな
パソコンで良い案件だと尚更SQL Server不要
ExpressでいけるならAccessランタイム配布で足りる >>125
小規模なら一台だけPCつけっばなしにしてサーバーとして使えば良くない？
二四時間365日ついてなきゃいけないわけでもないだろうし MariaDB or PostgreSQLに
フロントエンドがOpenOffice Base
が無料で構築出来るけどね
OpenOfficeで使ってるJava部分をOpenJDKでカバーする必要有るけど
(32bit版限定、半年毎に大幅修正)
フロントエンドをAccess、FileMaker、Baseどれを選ぶかは状況次第だがFileMakerはiOSデバイスとの拡張がメリットの割にライセンス料金高い 10人以下の小規模ならそのままaccess単体で問題ないですか？ >>128
使い道や頻度による。
検索メインで入力が1人か2人なら、もっと大人数でも大丈夫だし、
全員で毎日数十件の入力をするなら、バックエンドDBが必要だと思う。 安全も為にもMariaDBかPostgreSQLをバックエンドで持ってても良い
どうせフリーだし 環境: windows10、access2013
テーブルに格納されている「長いテキスト型」のデータをフォーム上のテキストボックスに連結して表示させると文字化けしてしまうのですが考えられる要因は何かありますか？ >>127
Filemaker高いな…
iOSで使うような会社だと他に >>131
WindowsPC上はアスキーコードになるが元データがコード違えば文字化けする >>126
クライアント用Windowsをデータベースサーバーに使うのはライセンス違反
なんだよ >>135
でもaccessなんかでそうやってやれって書いてあるよね >>135 困ったことにMSってクライアントwindowsだろうが
windowsサーバーだろうが、システム的に全くCALをチェック
しないんだよね。サーバーOS＋１０CALで25万円弱、に
理解を示せる社長さんかどうか。
（業務用アプリにACCESS開発を試みてる時点で事業規模は
大きくないはず）
いっそ、linuxにしてしまうという選択肢もなくはない。
多少なりともGUIでできる幅が広がってるので。 デスクトップPCにLinux入れてポスグレとかMySQL入れるの？
オペレーションは電源切るくらいならGUIあればできるだろ、と
MSのライセンス的によくわからんのが、クライアントWindowsのHyper-VにサーバOS載っけて運用できるのかってことだか やるなら、Linux上のOracleXEにクライアントAccessでやりたいな
Oracle＋AccessなんてちょっといいじゃないかVBの時代を思い出して ドライバ入れるのめんどくさいな
やっぱりWebが楽 >>133
ありがとうございます、また確認してみます Accessの場合、インデックスの断片化は「データベースの最適化」で解消されるのですか？ >>138
WindowsPC用のMariaDB,PostgreSQL有るべ
まあLinuxサーバー(デスクトップ)でもかまわんが まあ古いWindowsPCにUbuntu入れてMariaDB,PostgreSQL入れればデータベースサーバーになる
Linux distribution個々のライセンスの問題有るが、Windows CAL回避するにはこういう方法になる >>141
webプログラミングでしょ。ちょっとやってみたけど、なにせvbaの頭でやってるとjava系言語は難しい。
全部クラス呼び出し、非同期処理その他諸々、画面作るのににマウスの出番が一切ない、などやるべきことが多すぎる。
かといってkintoneのようなお手軽webDBも取っつきにくい。 >>143
断片化とは具体的にどういう症状でしょうか。
壊れたから開けねー、みたいなアラートが出たら「最適化」は修復を兼ねてるので、直ります。
ただし、壊れたやつは普通にデータ飛んでることもあります。親子関係結んだ親テーブルのレコードが飛んでるとか。 >>146
高度なことやらないならVBの生産性はまだまだ現役ってとこですかね、スレ的にも
そんな方のためのASP.netのWebフォームは滅亡してしまったし、
抽象化とかイミフなおっさんプログラマー達には厳しい
ExcelもこれからはPythonで制御するとかって方向性もあるし AccessなんてVBに帳票出力機構とFORM生成機構追加したモノ、と考えれば良い
DBの代わり、にはならない
フロントエンドツール
バックエンドDBは別途、無料のモノ用意する
サーバーすらLinux、MacOSにすればCALなんて不要
(クライアントOSライセンスは仕方ない) >>150 クライアントアクセスライセンス。
スレチだけど、windows serverは１ハードウェアサーバーに
１つの役割しかさせないというのが常識だそうで
sqlserver用に１台、認証サーバー（ActiveDirectory)に１台
共有フォルダ用に１台って、なんでユーザーのログイン管理の
ためだけに
１０人分で５０万円近い金はらわなきゃならんのか、いまだに
納得いかない。 >>151
といってもそんなもまもってる馬鹿いないよね？ >>152
大企業はサポート受ける手前守ってる
中小企業は知らん
Windows Server使うメリットは現在では少ない
Linux,MacOSサーバーで済む 1つのサーバーに複数の役割を持たせるのは別にライセンス違反ではないでしょ
それでサポート受けられなくなるとかあるの？ Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
DB更新にもウエイトとか入れないとダメなのか？
そんなシステムじゃクラサバで使えないと思うんだが >>156
>>Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
昔からね
リンクテーブルに更新かけるのは基本的にしない様にしてる
ODBC経由で更新かけると大概タイムアウトくらう >>156 やっぱりおたくも調子悪い？
２人くらいまでの同時更新なら壊れないんだけど
３人くらいになるともうだめ。
壊れにくい方法としては、オートナンバーやめて
インクリメントの覚書きテーブルから払い出させる方法。
最終的にはDBサーバー使う方が確実だったりする。 SQL Serverにリンクテーブルでつなげて更新してるけど特におかしくなったりはしないな
それじゃ遅くて仕方ないって場合はADOでT-SQL投げてるけど SQL Serverはマイクロソフト製品ゆえ、だと思う
他のDBはODBC経由での更新では何らか制限が有るのかもね
https://oshiete.goo.ne.jp/qa/6594834.html
ここにも有る様に主キーをDB側のテーブルに設定しないと無理らしい ■ このスレッドは過去ログ倉庫に格納されています
