Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ >>42
パッケージってこっちがあわせなきゃだから大変ですよね
業種が特殊だと何かと適応できないところありそうだし
daoもadoも何が何かよくわからない
いちからはじめる感じなのでそれならadoのほうがいいんでしょうか？ >>40
>>いまはEXCELとVBAで力技で転記しまくってデータベースのようにしています
EXCELはDBの代わりにはならんよ
事故の元だから止めとけ
>>ACCESSはフロントエンドにして
sql serverやmysqlを使え、とか書いているところもあります
個人的にはFreeのMariaDBかPostgreSQLをお勧めする
MySQLはOracleがその内課金する
>>ACCESSのデータベースは使わないほうがいいのですか？
容量上限が有る >>40
フロントエンドはアクセス以外にもOpenOfficeのBaseとかも使える
無理にアクセスに拘る必要性無い >>40
その内容なら DAO ですかね
Access 2007 から既定の DBエンジンが ADO から ACE(DAO) に変わっている
接続先が Access DB の場合は ADO より処理が高速、などが理由です
将来 SQL Server への移行を考えているのなら ADO の方が良いと思います
接続先 DB に関しては
SQL Server を候補に挙げられる環境なら、わざわざ MySQL を選ぶ理由はないと思います 私、sqlserver expressをかなりグレーな使い方してるw
MSってwindows serverもsqlserverも
cal数をシステム的に管理してなくて
大解放状態なので、どこまで何が許されるのか今一わからない。
サイト内の購入ガイドも「abcがcdeでbbse をselでgh5yiofがactiveXです」
みたいなルー大柴だし。 >>44
sqlはそれぞれ構文とか違うんですか？
>>45
VBAがないからいろいろできなくないですか？
>>46
DAOでやろうと思います
デメリットはとくにないんですよね？
SQL Serverは起動させておくというかサービス扱いなので使い勝手が悪いですよね >>48
SQL文はDB毎に方言有る
OpenOffice BaseもVBAの代わりのスクリプトとか有るよ はじめてACCESSをフロントエンドにしてmysqlで作ってみようと思います
まずは簡単なコレクション管理をつくってみます
ACCESSのみでやるときと、どのようなところから違い
注意するところなどありますか？
直接sqlを書きまくらないなら今までどおりACCESSとVBAで作ればいいんでしょうか？ >>48
> SQL Serverは起動させておくというかサービス扱いなので使い勝手が悪いですよね
DB サーバーを置く予定がないのであれば Access だけで完結しそうですね
がんばってください >>50
MySQL使うよりMariaDBの方が先々安全だけどな >>50
DB---MySQL(MariaDB)
にODBC接続して各テーブルをクエリーで加工したらFOMEでもレポートでも展開出来る
SQL文直接書き込みなんてしない
VBAもよほど複雑な処理しないなら不要 MariaDBとACCESSのみでやるのはどういうところに違いがあるんですか？ >>55
どの程度のデータベースだとACCESS単体だときついですか？
単純にレコードの目安的なものありますか？ >>54 まずテーブルを外だし（別ファイル）して
それにリンクさせるところからトレーニングを始めましょう。
詳しくはACCESS初心者入門本などで。
分離されたテーブルファイルが狭義でのデータベースに相当するもので、
ACCESSのフォームやレポートはユーザーインタフェイスです。
ACCESSを分離する一番のメリットは、2人以上で作業するときに
テーブルファイルを共有できることです。
ただし、ACCESSは、共有のしくみが有能ではないので
複数同時作業の場合は、最初から上に紹介されてるような
DBサーバの導入をお勧めします。
（ACCESSで共有やると、本当によく壊れる）
もちろん、一人親方が当分続くようなら無理する必要はありません。
売り上げに直結する時間を無駄にすべきでないからです。 >>57
一人親方から脱出できそうなとき、
他のDBサーバーに移行するのは簡単ですか？
組んでいたVBAなどが正常に動作するか、といった不安があります
ちなみに数十人雇っている同業他社から送られてくるデータはEXCELのみで、どうもDB化されていないようで 転記ミスや送信ミスが多いですね
事務の女の人が大勢でExcelに打ち込んでコピペと手動で精査しているみたいです
システム目安としては、。
EXCEL→ACCESS→ACCESS（外部DB）→システム屋に委託
という感じでしょうか？
社員が数人のときにシステム屋に頼んでも金を取られるだけですよね ところでACCESSでやるのって
販売した個数や金額を保持させて月末払いの取引先への請求書をつくるって感じですよね？
その請求書データを会計ソフトなどにインポートしているんですか？
簡易的に、
販売
仕入
のテーブルをつくって、指し引きして粗利をだす
というようなことまでやっているかたいますか？
会社全体ではなくとも部門ごとに把握するためとかで
うちは月単位で税理士に頼んでいるので
会計はやっていません
請求書データを渡しているだけです
会計ソフトのように勘定科目とかでわけるわけでもなく
ざっとした経費と売上で毎月の大まかな儲けをだしたいです
ACCESSからEXCELにインポートして任地の表上でコピペしまくってやるものでしょうか？ >>56
アクセスは2GB制限が有る
http://sasamm.hatenablog.com/entry/2018/03/25/175045
この制限有る内はアクセスだけでDB活用とか普通は考えない
テーブル部分だけでも別DBとして保持する >>58
>>転記ミス、送信ミス
システム的な教育受けて無い社員で行う場合はついて回るミス
キーパンチャーみたいな扱いで女子社員使うのは、その社員もストレス抱えるし、専任の担当者を任命するのが普通
他の業務と並行でやらせるのはミスmの元だし、システム開発も予定通り行かない
Access得意なヤツなら業務内容説明したら、相応のテーブル設計してフロントエンドとしてAccessでFOMEとレポート作成して終わりだろうな >>59
小さな会社だと分離というか、会計士任せのとこも多いですね。
それを総合的に繋ぐのがERPというシステム群です。
obcであれば請求書発行（回収管理）までが商奉行、仕訳など財務諸表を作るのが勘定奉行で、バラバラに買うよりは
処理が減ります。
ところで、売上記録は実はAccessの教科書通りにいかない特殊性があります。
「正規化しなさい（冗長性を排除しなさい）」が基本ですが、商品マスターの単価が変わるのに明細に単価を持たせず参照にすると、請求書の整合性が壊れます。
よって商品名、単価、金額、得意先名など、基本的にはすべて冗長性をもたせた記録をする、というやや特殊な案件です。
これに頭悩ませるよりは、10万円くらいからの売上管理ソフトを導入してみてはいかがですか。
（ちなみにガチのERPだと売上管理部分だけで5年ライフサイクルで1千万円かかります） >>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
ありがとうございます、また確認してみます ■ このスレッドは過去ログ倉庫に格納されています
