Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい・いいえ
【 VBAでの回答 】 可・否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ >>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
どういう設計(システム的に)って話
これは経験しないと分からない >>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+10CALで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は1ハードウェアサーバーに
1つの役割しかさせないというのが常識だそうで
sqlserver用に1台、認証サーバー(ActiveDirectory)に1台
共有フォルダ用に1台って、なんでユーザーのログイン管理の
ためだけに
10人分で50万円近い金はらわなきゃならんのか、いまだに
納得いかない。 >>151
といってもそんなもまもってる馬鹿いないよね? >>152
大企業はサポート受ける手前守ってる
中小企業は知らん
Windows Server使うメリットは現在では少ない
Linux,MacOSサーバーで済む 1つのサーバーに複数の役割を持たせるのは別にライセンス違反ではないでしょ
それでサポート受けられなくなるとかあるの? Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
DB更新にもウエイトとか入れないとダメなのか?
そんなシステムじゃクラサバで使えないと思うんだが >>156
>>Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
昔からね
リンクテーブルに更新かけるのは基本的にしない様にしてる
ODBC経由で更新かけると大概タイムアウトくらう >>156 やっぱりおたくも調子悪い?
2人くらいまでの同時更新なら壊れないんだけど
3人くらいになるともうだめ。
壊れにくい方法としては、オートナンバーやめて
インクリメントの覚書きテーブルから払い出させる方法。
最終的にはDBサーバー使う方が確実だったりする。 SQL Serverにリンクテーブルでつなげて更新してるけど特におかしくなったりはしないな
それじゃ遅くて仕方ないって場合はADOでT-SQL投げてるけど SQL Serverはマイクロソフト製品ゆえ、だと思う
他のDBはODBC経由での更新では何らか制限が有るのかもね
https://oshiete.goo.ne.jp/qa/6594834.html
ここにも有る様に主キーをDB側のテーブルに設定しないと無理らしい 【 システム環境 】 Windows7, Access2016
【 VBAが使えるか 】 いいえ
【 VBAでの回答 】 否
【 検索キーワード 】 テーブル、クエリ、違いetc
初学者です。
テーブルは基本的な情報、クエリはwhere句やjoinなどなんらかデータを加工したものという認識ですが
クエリ→デザイン→テーブルの作成の意味が良くわかりません。
テーブルから抽出したデータをクリエと呼ばずテーブルに定義するのはなんかおかしいと感じるのですが
どう考えたらいいのでしょうか? 抽出データをごにょごにょして実体データを作りたいことないの? >>164
Access諦めてFileMaker使えよ Access使うならテーブルとクエリーの違い分かって無いと何とも
クエリー使いこなすのがAccessのキモだからな
VBAはどうしてもクエリーで対処出来ない場合やマクロで対処出来ない場合のみ使う
何でもかんでもVBAとかで対処したがるVBプログラマーの作ったAccessなんか仕様変更した場合メンテナンス出来ずに死ぬ >>164
その認識で正しいし、ACCESS内でもクエリーはクエリーで
テーブルと呼ぶことはありませんが。
クエリーを擬似テーブルとして、違うクエリーで再利用することはできます。
もしくは「テーブル作成クエリー」のことですか。
あれは、クエリーの結果をテーブルに書き出すもので、
SQLで表現すると「SELECT * INTO ナンチャラ FROM ナンチャラ WHERE ナンチャラ」です。
違うことが聞きたいのであれば、少し表現を変えてみてください。 >>168
下段のほうです。アクションクリエのテーブル作成クリエって言うのがいまいち使いどころというか存在意義が良くわからなくて。
でも、>>166さんの書き込みも踏まえて考えると別のデータベースに移すとき実体データを整えるのに使うのかなと思ったり。
よくわかりませんが。 × >>166
○ >>165
引用間違えましたすみません。 >>テーブル作成クエリー
中間テーブル作成
クエリーにクエリーを使うより確実だから中間テーブルを作ったりする
データ抽出結果も確認出来る 中間テーブル・・・はじめて聞く言葉ですがなんとなく解ってきました。
ビューみたいなものととらえれば大丈夫ですか?
違ってたらすみません。 >>172
いやmdb内部に作る作業テーブル
最終的な帳票なり、画面の元になるテーブルを作る前の途中経過のテーブル >>172
ビュー=(普通の)クエリーです。
中間テーブルは、SQLSERVERでいうところの一時テーブル(#TABLE)
です。ただし、ACCESSではライフタイムがないので、そのまま残ります。
一時テーブルの使い道は色々あります。レポートの呼び出しの時に
先に対象レコードを1個だけに絞っておきたいときとか、
前後のクエリーがくどい記述になる時とか、
VPN経由で回線が細い場合にレコード1個分だけ引っ張って
ワークテーブルとして利用するなど。 中間テーブルとクエリーをどう活用するか
がAccessのキモ
FileMakerにはAccessのクエリーに相当するモノが無い
SELECT文をスクリプトとして実行するか、テーブルオカレンスを使う
帳票ツールとして見た場合、Accessの方が安くて応用が効く
FileMakerはデータ保持容量の大きさとクエリー、VBAを使いこなせ無い人向けのDB(WebやiOSデバイスとの連携もメリット有るが)
何にせよFileMakerのライセンス料金の高さは中小企業には厳しいレベル 中小企業でFileMaker使ってる所は今後厳しいだろうね
ランニングコスト考えたらMariaDBやPostgreSQLとAccessの組み合わせの方に分が有る
OpenOffice BASEも有るし
iOSデバイス使ってないならFileMaker使うアドバンスは無い >>169
SELECT * INTO [EXCEL(バージョン) ;Database= (ファイルパス) 〜
とかで、1ブック内に複数の新規別シートで出力する時にも使えるよ。 いろいろレスありがとうございます
ビュー=クリエは目からうろこでした
レスを元にいろいろ調べながら考えてみましたが中間テーブルを作るということはクエリと違ってSQL文を実行する手間が省けるわけでデータが大きくなるのに比例して演算時間の短縮効果が大きくなるのかなと思いました。 >>183
まだSharpポケコンPC-1480Uが現役なので、次はシグマリオンに機種変更します。 昔はレプリケーションとかWebコンポーネントとかpdfのコントロールとかあったのに滅びたの代替できるのないの 質問です。
AccessでUnicode文字を扱うにはどうしたらよいのでしょうか?
立方メートルの記号である㎥など、Unicode文字を扱いたいのですが、イミディエイトウインドウでもメッセージボックスでも ? になってしまいます。
イミディエイトウインドウで ?MsgBox(ChrW(&H33A5)) とやっても同様です。
何か方法があるのでしょうか? >>186 の環境は Access 2013 です。 【 システム環境 】 Windows10, Access2010
お願いします。
データは入ってなくてもテーブルでフィールドを用意するだけでサイズは大きくなってしまうのか、
という疑問を持っています。
たとえば、家族テーブルというのを作るとして、
1レコードに、世帯主、家族1、家族2〜家族6までのフィールド構成にする場合と、
1レコードに、家庭id、家族内番号、名前、というフィールド構成にする場合、
どちらがPCに負担がないのか、ということです。
夫婦だけとか一人暮しの人も多いので、前者の構成だと空白だらけになります。ほとんどのレコードでは
データを入れる機会がないのにフィールドだけ6人分も用意するのはもったいない気もします。
しかし、後者だと、一人1レコードなのでレコード数が多くなるし、家庭idで複数レコードを
引っ張ってきて家族内番号で並び替えたりする処理なんかだと、かえってPCに負担かな、と
思ったりとか。。
一般論ですが、こういうの、どんなもんでしょうか? Docmd.applyfilterで急にエラーが出始めた。
strFilter="Replace([col1],'hoge','fuga')…のところがエラーになるようになった。
昔はreplace関数でエラーになったが、ある日実験していたら、なぜか急に使えるようになったので、そのまま使い続けていたら、急にエラーが出るようになった。
なんで突然挙動が変わるのでしょうかね? >>186
Access と VBA は Unicode に対応していますが
開発環境(VBE)とメッセージボックスは Unicode に対応していません
・Unicode 対応版のメッセージボックス(API)で表示
・メッセージ用のフォームを作成して表示
こういった方法になります >>188
1テーブルもアリです。10くらい作っておけば十分でしょう。
家族の名前を検索することもないでしょうし。
せいぜい法定福利関係のレポートに印刷するのに使うくらいでしょ。
もし、年齢が扶養家族に適合するか、みたいな属性もたせるのであれば分けた方がいいかもしれません。 ■ このスレッドは過去ログ倉庫に格納されています