Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい・いいえ
【 VBAでの回答 】 可・否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ ここで聞いて回答待ってる間に自習でどんどん進むぞ
Access Excel Export とかで検索すりゃ、ゴロゴロ
そン中から自分が欲しい・望むカタチをある程度固めてから
質問した方が、よりコアな回答が返ってくるはずだし
その質問だと漠然とし過ぎ
因みにグラフの種類はExcelには叶わない 見た目重視なら尚更
ストアからE2D3入れればより豊富に >>18
コピーペーストのコードが乗っていたので記述し試してみると
そのままエクセルに出力できました。
ここからグラフ化するとなると
エクセル側でボタン等を配置し、マクロを組み込めばいいのでしょうか? >>17
すみません、これは適当に打ち込んでました…お恥ずかしい Excel側は、取り込むSheetとグラフSheetを別にしとけば
Sheetにデータが入った時点でグラフも更新されるだろ まあ、別じゃなくてもいいけど
サンプルデータで気に入ったグラフの様式を作っとけば
次回からは入ったデータに応じてグラフも可変するわな マクロ組むまでも無い >>22
なるほど、スレチ?だと思いますが答えていただきありがとうございます。
知識0から始めて、ネットで調べて、全部丸写ししてるようなものなのでこれが勉強になってるのか不安です…みなさんそのようなものなのでしょうか? >>23
なんでグラフ表示にExcel使うのか分からん
Accessでも出来るだろ
https://support.office.com/ja-jp/article/フォームまたはレポートのグラフを作成する-1a463106-65d0-4dbb-9d66-4ecb737ea7f7 >>24
AccessのグラフはExcelのグラフに対して、
機能が落ちたり制約が多い。
ちょっと試すと、直ぐわかる。 昨日エクセルへ出力で質問させていただきました。
コピー・ペーストの方法にて、検索結果をエクセルに出力することが出来ました。
コード等は画像を貼り付けておきます。
この状態でほぼ完成だと思って入るのですが、出力したデータを自動的に(半自動的に)グラフ化したいと思っています。
温度であれば、温度差など
項目別にグラフ化できたらなと思っていますが、無理なのでしょうか?
https://i.imgur.com/JTxWUZg.jpg
https://i.imgur.com/J0cWzHK.jpg
https://i.imgur.com/A5zrbT0.jpg コピー・ペーストするから毎回新しい Book を作ってしまう
なんで上の方で Export のアドバイスをされてるのにそっち選ぶかな
まぁ、コピー・ペーストでも CreateObject じゃなきゃいいんだろうけど
最新のだと Office Link ?だともっと楽らしいが 自分もexcelにシート分けて出力するvba書いたことあるけど、access vbaに慣れてるとcellsどうのこうのとか、
excel vbaってえらいしんどいよね。 Excel2016なら、逆にExcel側からインポートを選んで
ソースはAccess テーブルかクエリを選んで引っ張れる
下手にAccessでVBAで混乱するより、そっちのが百倍楽 【 システム環境 】 Windows8.1, Access (Office365を使用)
【 VBAが使えるか 】 はい
【 VBAでの回答 】 可
作成したデータをマクロを使用して帳票印刷しようとしています。
「レポートを開く」のオプションを使って、where条件式で表示する条件を入れようと思っています。
IIF文を使うなどして条件分けしたいのですが、条件式の中に文字列が入りきらず
式が不完全になってしまって動かせません。
既存の改修なのでフォーム名やプロパティ名を変更するのは難しいです。
条件式に入力できる文字数を調整、あるいはプロパティ名などを短縮して
記載する方法はないでしょうか? 既存の改修ったってフォームやレポートは新規作成できるんだろ?
新しく作ったフォームで条件式の面倒を解決して
そこからレポート作ればいいんじゃ? >>31
入り切らないくらい長いのであれば
Where 条件で中間テーブル作成して
そのテーブルをレポートで参照する
のが定石ですかね >>32-33
ありがとうございます
新規にフォームを作るよりは中間テーブルで挑戦する方がいいかもしれません
試してみます AccessのMDBのDB部分だけをクラウドに移行しようとしているんだけど、注意点はありますか? 巨大なフォームと多数のコントロール類があります。複数のタブコントロールに分割して、その中にコントロール類を配置したのですが、どうも動作が遅いような気がします。
タブコントロールにコマンドボタンとかテキストボックスを多数配置するとスピードが遅くなるものなのでしょうか?
なにか資料はございますでしょうか? >>38
多少は重くなりますけど、そんなには。
まさかCPUがペンティアムMMXでwindows95じゃないですよね。
入力オブジェクトを数千個とか並べない限りはエントリーモデルのpcでも動作に支障ないはずです。
データファイルと分離されたフロントエンドファイルの場合で数十ギガのサイズになってませんか?
画像などの表示域を複数配置してませんか? 個人経営レベルの会社をやっています
売上と請求書を作成するものをつくろうと思います
ado daoどちらでつくればよいんでしょうか?
いまはEXCELとVBAで力技で転記しまくってデータベースのようにしています
ACCESSはフロントエンドにして
sql serverやmysqlを使え、とか書いているところもあります
ACCESSのデータベースは使わないほうがいいのですか?
また、移行する必要がでたとき、あとからでは取り返しがつかないものでしょうか?
今はひとりでしかつかいませんが
そのうち数人で使うこともあるかもしれませんし
ないかもしれません(業績しだいなので) このタイミングなら消費税増税来年だし、せっかくだから適格請求書に対応するように設計すれば? >>41
適格請求書って初めて知った。勉強なるわ。明細ごと消費税付加式なのね。
>>40 daoで慣れてるなら無理にadoにすることもない。操作性変わらないし、どうやらMSも完全移行方針を取り下げたっぽいので。
Accessデータベースは1人で使うぶんにはあまり壊れないけど、複数名同時使用したとたんに壊れやすい。
データベースサーバーのほうが圧倒的に複雑クエリーが速い。
いずれにしても個人事業主以上まで
成長したらパッケージ買った方がいいですよ。 >>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の挙動が変なのでちょっとコツが入りますが)
請求は、参照閲覧用としては上に同じですが、締めという概念が入ってくるので、最終的にはいくら請求したかというテーブルが1個必要になって来ます。 >>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
どういう設計(システム的に)って話
これは経験しないと分からない ■ このスレッドは過去ログ倉庫に格納されています