Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ バージョン：オフィス365
アクセスの初心者です。
今まで社員登録、給与業務の検算、集計などをエクセルで行ってきまいたが、ファイルが重くなったのと他の職員との関わりからアクセスに取り組んでいます。
毎月、最新の人事、給与データなどをエクセルにエクスポートして計算していこうか考えていますが、壁にぶち当たりまくってます。
今のところ、複数のテーブルにデータを入力してリレーションシップをつなげています。
テーブル?；社員ID
テーブル②：氏名、住所、入職年月日他
テーブル③：給与データなど
テーブル④：社保情報など
これをもとにフォームを作成して新規職員の入力、情報の変更をしていきたいと思うのですが、それぞれテーブルごとフォームを作成するとIDしか表示されないフォームとなっていまい困っています。
どのフォームにおいてもID氏名を表示させるにはどうしたらよいでしょうか。 フォームのおソースをクエリにする
VBAならIDの更新で他のテーブルから呼び出せるが >>3
新規入力→追加クエリ
訂正など→更新クエリ
こんな感じでクエリを作成して社員管理していくのがいいでしょうか。
やはりVBA使えないとダメですね。見直します。 社員何名か知らんけど 300人以内ならアマノのタイムレコーダーにしとけ
勤怠管理ソフト付きで八万で済む 事務員の給与半月分 1/3か？
その勤怠ソフトはデータベースにmdb使ってるけど
https://nihonkiki.com/products/detail.php?product_id=1561&;gclid=EAIaIQobChMIiayc7Lmg3QIViQQqCh0WmANIEAYYAiABEgIIhvD_BwE
慣れない業務で無理からシステム構築しても後日のトラブル頻発の元 >>4
んにゃんにゃ、まだvbaの出番ではない。
3で書いてるとおり単純なクエリーを保存してそれをフォームのレコードソースにする。
各テーブルのカラムは社員マスターでは社員idがキー列、
他がidなどの名称で自動符番にしてキー列、さらに社員idをもつ列をもたせる。
実績記録用テーブル全列（社員id結合）社員マスター（必要な列）でクエリー保存。
フォームウィザードとかで単票フォームを生成する。
社員idのとこは手入力かコンボボックス（社員マスター参照）。
これで社員名などが出てくる。
50人以上なら検索専用フォームを作ったほうがいいが、やや難易度高いので今はパス。
社員マスター参照部分は間違って触るとマスターも更新してしまうので、社員名諸々にはプロパティで更新許可を「いいえ」にする。 >>6
レスありがとうございます。
すべてつなげてクエリ作成しましたがフィールドが多くなりすぎてしまって単票フォームでは収まりません。
今、考えているのはテーブル1をＩＤ＋氏名に訂正。
テーブル1＋テーブル2で1つ目のクエリ
テーブル1＋テーブル3で2つ目のクエリ
〃
〃
タブのフォームにまとめようと思っていますがどうでしょうか。 >>7
普通にそんな感じ。
実績用テーブルで社員マスターの参照が必要なのは名前とか、その場その場で必要な基礎情報だけクエリーに含める。
見えやすさの観点からはタブが有効。フォームでは今時のpcならフィールドが50だろうが100だろうが動作に支障はない。
何かの計算の基礎情報で、見せる必要のないフィールドは適当に空いてるところに寄せ集めて「可視」を「いいえ」にする方法もある。 【 システム環境 】 Windows7, Access2010
仕事で初めてAccessを使うことになりました。
したい事はVBAでAccessからOracleへのエクスポートです。
OracleはODBC接続です。
DoCmd.TransferDatabase acExport,・・・・・
これでエクスポート自体はできました。
問題なのはAccessのテキスト型がOracleへエクスポートするとvarchar2型になる点です。
Accessのテキスト型は文字数とAccessで表示されるので全角でも1文字数と思います。
しかしOracleのvarchar2だと全角は2バイトになるはずです。
結果、Accessテキスト型10はOracle varchar2(10)にエクスポートしようとするため
全角のみだとOracleのvarchar2(10)に収まらず、エクスポート時にエラーとなってしまいます。
エクスポート時に文字型をVarchar2でなく、NVarchar2にエクスポートする方法はあるのでしょうか？
仕事中は書き込めないのでレスは夜しか出来ませんがご了承ください。 >>9 なぜVBA使ったのかわからん。
Access2010という古いバージョンが一因じゃない？
select intoがうまく機能しないんだよたぶん。
自分なら、oracleにテーブル作ってから
odbcでリンク貼って
insert into 文使うけど。クエリー画面で挿入クエリーでもいいし。 >>10
簡潔にAccess -> Oracleと記載したんですが、
Accessに入るデータはいろんなシステムの大量データとなります。
SQL Server -> Access -> Oracle
Access -> Access -> Oracle
Excel -> Access -> Oracle
という感じで、Excelだけでも何百というファイルです。
そのため全てのテーブル作成SQLを作るだけでも膨大な作業になるため（特にExcel用）、
Accessのエクスポート機能を使うようにと指示が出てます。
この機能だとOracleにテーブル準備しなくてもエクスポート時に、勝手にテーブル作ってくれるからです。
Access2010は確かに古いので、単に最新のAccessだといける可能性はありそうですね。
稟議はとおって購入できるので、環境できたら試してみます。
情報ありがとうございます。 今日、Access2010から2016にして試しました。
が、やはりOracleではvarchar2になってしまい、だめでした。
仕方なくSQL ServerとAccessのデータは構造だけエクスポートし、
create文を生成してvarchar2をnvarchar2に置換え、テーブル作り直し、
テーブルありきでVBAからINSERT INTOする方式にしました。
マイクロソフトに電話したんですが、北海道の地震影響で技術的回答は無理で、
来週問い合わせし直してくださいと言われました。
今日が納期だったので上記の方法で対処したので、この質問は完とします。 sqlserverだと公式な関連ツールにmigration toolってのがあるが
oracleにはそういうのなかったっけ？
ソースにexcelも含まれるって、よく今までユーザーが
データ規則を守って入力してきたものだ。普通、どこかの行でコケる。
自分なら
select top 1 into で一旦作る
deleteで空にする
ストアドプロシージャでテーブル名を引数にして
総当たり的に型を変更するalter tableを生成するやつを作っておく
もう一回 insert intoでデータ入れる
ってのをVBAのadoあたりを使ってぶん回すかな。 >>12
>>AccessからOracle
早くて確実な方法は
*Oracleであらかじめテーブル領域確保
項目属性はOracleに準じて確保
*AccessからデリミタでCSVファイルでテーブル出力
*そのCSVをOracleへSQLローダーでロード
これが早くて確実 >>12
テーブル多いからVBA使うのは理解出来るがテーブル定義がキッチリしないままエクスポートで勝手に決められるので良いかどうか
SQL ServerのテーブルをOracleに移行するのは分かるがAccess、Excelのデータもテーブル化する必要性は不明だな
項目属性がおかしい場合、テーブル定義後から変更すんのか?
指示出したヤツはAccess知らんやろ 2010
すみません、現在このフォーム（詳細内）に、日付期間を指定し検索ボタンを押すと入力していたデータがサブフォーム内に表示される簡単な検索画面を作成しました。
この表示されたデータをエクセルに出力したいボタンを作りたいです。
また、その先でそのデータを用いてグラフ化（アクセスのグラフを使えばいいのか、エクセルのグラフ化を使えばいいのかわからない）したいとも思っています。
教えてください。
https://i.imgur.com/xZkQ8KG.jpg ここで聞いて回答待ってる間に自習でどんどん進むぞ
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でレコードメンテナンスするのと帳票はタイミング違うだろ ■ このスレッドは過去ログ倉庫に格納されています
