Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ ▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━ ★ OS、ACCESSのバージョンを明記してください。 ★ 質問内容は具体的に書いてください。 ・何がしたいのか ・どんな処理を試したか ・動作状況など駄目な理由 テーブル/フォームの構成、クエリ、VBAの内容など差し支えない 範囲で詳しく書くと、早く回答が得られるかもしれません。 図解があれば尚良し。 聞き返さなくても詳細が把握できる質問が望ましいです。 ★ 事前にヘルプ・Google等で調べられる範囲は調べてください。 大概の疑問は検索することで解決します。 ★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。 ギブアンドテイクで情報を共有しましょう。 ▼━質問テンプレ ━━━━━━━━━━━━━━━━━ 【 システム環境 】 Windows**, Access** 【 VBAが使えるか 】 はい・いいえ 【 VBAでの回答 】 可・否 【 検索キーワード 】 Googleやヘルプでの検索キーワード 前スレ Access総合相談所 27 http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ 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 どういう設計(システム的に)って話 これは経験しないと分からない >>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)) とやっても同様です。 何か方法があるのでしょうか? ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる