Access総合相談所 31
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ 質問内容は具体的に書いてください。
業務上の守秘義務も大事ですが、貴方の所属組織を特定できるほど、特異な業務・システムは滅多にありません。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
前スレ
Access総合相談所 30
https://mevius.5ch.net/test/read.cgi/bsoft/1617766381/ えええMicrosoft365のAccessもなくなるのでしょか
こまったかな >>294
さすがいサポ切れアプリで新規は無理
保守で動作保証できない
アプリはExcelでDB直に叩く
流石になくならないだろう えー、エクセルでフロント？
だったらサポ無しアクセスの方がマシじゃね？
ユーザがおkすればだけど >>298
サポ切れのソフトで開発って客が納得するとは思えない
ランタイムだけ残るなら別だけど どうかな
アクセスとc#じゃ、開発費が段違いやからな >>297
>>ExcelでDB
あまりやりたく無いな、、
しかし続くだろうね、、 ウンコメーカー使いだけどそれはどうかな
マトモなユーザは呆れ果ててるよ
守銭奴ライセンスもあるけどそれよりバージョンサポート期間の短さ
そのたもろもろある FileMakerダメなのか
1バージョンのサポート期間が短いのは困るな
ランタイムなさそうだし、シングルライセンスじゃDBの共有できなそうだし、スクリプト覚え直すのムリ
ちょっとした管理システムに結構使ってる会社多そうだけどな、Access 家電量販店だかでアクセスとSQLサーバで基幹開発してたけど
どうすんだろ ウチの会社もフロントエンドをACCESSで作ってる
すごく機能アップしなくても良いから今まで出来たことをこれからも出来るようにお願いします
まだ64ビット化してない困った困った >>307
客によって64/32混在だから、両方の環境用意してる
Access上のアプリしか管理してないから、客のOffice導入によって64/32変えるの勘弁
一度64の環境で32のコード動かなくて焦ったのは昔の話 あんまり理屈わかってないけど、とりあえずptrsafe って書いとけばいいか、みたいに64ビット環境をしのいでる。 postgreで使うSQLファイルの構文検証のために初めてACCESSでクエリ実行しようと思ったが難易度高くて苦戦してます
【やりたいこと】
データ管理してるエクセルからVBAでSQLファイルを作る→postgreに投入
作ったSQLの妥当性検証のためにローカルで動かしたい…手元にあるからACCESSでやるか
入れるSQLは
insert into AAA (カラム羅列) values (値羅列),(値羅列),(値羅列)…1500レコード位…(値羅列);
こんな感じ
SQLビューに貼り付け→長すぎてエラー
マクロで読み込んで実行→メモリ不足のエラー（SQLファイル110KBしかないけど本当か？）
大人しくpostgre入れろってのはそうなんですけど何とかならないですかね？ >>312
1500カラムならAccessじゃムリ
クエリーで110KBもムリ
確かカラムは255、クエリーは64kだったはず
正確な数はググって 元々複数行のINSERTに対応してたっけ？
昔コーディングしたときはUNIONで書いてたような…
この辺はSQL方言あるから、本番に近い環境でやるのが正解
Accessで通るからと言ってpostgreでも100％正常に動くとは思えん レコードだのカラムだの行だの混乱してるけど、1500レコード程度なら行けるじゃん
フィールドが多いってんなら一旦ワークテーブルとかを用意して絞っておけば
INSERT INTO tblNEW
SELECT * FROM ワークテーブル とかで済むんだし
ポイントは両方のテーブルを全く同じ構成(構造)にしておくことぐらい
つか、VBAってExcelの？ ExcelのPower Queryでなら処理できね？
テーブルあたりの列数 16,384 とからしいし それでワークテーブル作ってもいいような >>315
>>312はSQL文の検証に使いたいだけじゃね？ バカもね、たまには必要なんだ
やってもみないでバカと罵るのは簡単だけど、やってみて「あ、やっぱバカだな」っつーのと
じゃあ天と地の開きが出て来る バカなことしてみたけど、え？これでもいけるじゃん
とかいう見極め・ボーダーを知るのも制作者の務め
達人ほどその剣先を躱す見切りに秀でているのは、実体験してるかして無いかに負うところが
おおきい 口先だけ達者なのは生き残るのに難儀する ま、真剣だとその場でご愁傷様だけど 弄った瞬間にわかるようなこともわからず
製品仕様も知らず調べもしない無知無能蒙昧馬鹿だからもっと馬鹿と言ってやれ >>321
あーexcelのインサイダープレビューにpython来た話？
動画で使い方見たけど、けっこうカオスよ。
pythonってわりとライブラリー追加ありきだから
そこらへんもよくわからなかった。 Pythonはいいけれど、大量のライブラリどうすんだ？
参照設定みたいなので対応か あれ、365が必須？
でPython自体のインストールは不要？
PIPはコマンドラインでやんだよね？
アクセスもpy利用できるようになる？
つか、どうせならVBA無くしてPythonにすれば？ >>325
Excelだけだよ
クラウド実行ゆえ環境が限られる コンボボックスについて質問があります。
表示するしないの条件付きのクエリと無条件に全て表示するクエリを用意し、それぞれをもとに同じデータを格納するコンボボックスを作ります。
条件付きのクエリを基にしたコンボボックスの背景を透明にし、フォーカス取得時に再クエリを設定のうえ他方のコンボボックスに重ね合わせます。
表示するしないの条件を変更しても、データ入力も表示もできるのですが、使っているうちにコンボボックスのプルダウンするボタンをクリックしても、一瞬入力データを表示するのですが戻ってしまう現象が発生します。
もう一度クリックすればデータを入力できます。
対策方法がありましたら、ご教示ください。よろしくお願いいたします。 >>328
端的に答えるなら、,visibleプロパティ使ったほうがいいのと違いますの？
それより
何かの条件で全件選択可か絞り込み選択可を切り替えるんでしょ。
例えば、他の項目の入力内容によって選択条件を変えるんだったら
rowsourceのクエリを直書きsqlで書いてWHERE句入れて他の入力欄を指定したほうが
いいんじゃない？ リレーションシップについて教えてください
1∞の意味はわかったんだけど、どっちにも何もついてない場合はどういう意味になりますか？ >>331
リレーションシップってJOINだけじゃないんだね
SQLでどう書くんだろ T-SQLでのCreate Triggerみたいなのが知りたいんじゃなくて？ >>334
たまに見るfrom a,b って
デカルト積っていうんだ。
へえ。
使いどころがようわからん。 完全外部結合したいとき、Accessではどうしますか？ >>329
ありがとうございました。
うまくいきました。 >>337
それこそデカルト積のことかな。
テーブルa
1あ
2い
テーブルb
A ア
B イ
select a.*,b.* from a,b
1 あ A ア
1あ B イ
2 い A ア
2 い B イ 完全外部結合(full outer join)とデカルト積は別物だと思うけど で、完全外部結合したいとき、Accessではどうしますか？ せめてリンク先読んでから書き込みなよ
その上で分からないこと質問しなよ
この掲示板上だけで問題解決して欲しいってか
必要なだけ仮のクエリ作ってSQL文流用し、それをUNIONで繋げろってさ
貼り付けたリンクじゃ辿り着けないようだから再掲
https://www.accessdbstudy.net/entry/20080705/p1 馬鹿なの？
ネット記事に頼るならここでは聞かないよ ほおleftとrightのunion連結ね。
union allにしないところがミソだね。 なんで？ サイトの図入りの解説のが一目瞭然じゃん
文字だけでぐだぐだ長い解説書き込まれるよか、百万倍楽じゃん
長文書いたら書いたで三行にまとめろとか罵るくせに 五歳児か おとついきやがれ 完全外部結合とかデカルト積とかぜんぜんわからん
こういうのってSQL共通なの？
方言なら知識として使えない
最近はワークテーブルと単純SQLばかり
保守性メイン >>349
クエリなんて項目変わったときに検索できないから、全部SQLでOpen
ちゃんと最後に.CloseとNothingもやってるよ
ワークテーブル書き込みはBeginTrans/CommitTransが速いな >>350
VBAで保守性上がるが実行速度は遅くなる >>351
もちろん簡単なSQLはExeciteしてるよ
多少の動作速度低下はハードウェアの進化で吸収
デバック中に、トランザクション中にコードがエラーになってそこで止めるのを数十回するとVBA自体がエラー吐くんだが、なにか対策ある？ イベントビューアーでなにが起きてるか確認 メモリ不足のせいな気がしないでもない 過去の社員が作っていったaccessツールで、データを入力されたレコードを上から5個につき1枚のA4用紙に印刷するというものがあります。
しかし、データが5個以上あると上の4個のみきちんと表示され、残りは全く印刷されず、データの入っていないデザインビューの枠のみが印刷された紙が数枚出てきます。
なにか根本的な欠陥があると思うのですが全く検討つかず・・どなたか解決のきっかけだけでも助けてください。 >>354
レポートがどういう設計になってるかわからないんで、単純にテーブル/クエリーを明細セクションに設定してるとエスパー
日本に慣習である空白行がある伝票で、1ページ分の全項目を1レコードにブチ込むレポートも作るのたまにあるけど
レポートのRowSourceからテーブル拾って、レポート出したときにそのテーブルにレコードが内容、件数共正しく出ているか
レポートイベントでなにかしていないか
このくらいしか思いつかない
最後はコード追っかけるしか無い まず、マクロで組まれているのかVBAで処理しているのか
マクロは編集の仕方忘れてるけど、Alt + F11 押してコードが出てきたらVBAだと思う
出てきたら儲けもの 必死にコードを探って甘い処理のヶ所を特定して修正
それまでは、いちどきに5個以上のデータを突っ込まない運用をするしか回避策は無い 書き損ねたか Shiftキーを押しながらAccessファイルを起動するひと手間が欠け落ちてた
起動し終わるまでずっとShiftキー押して無きゃいけなかったっけ？ まぁ、そんな感じ
実行モードと編集モードとかいう切り替えが必要(それも制御されてる可能性もあるが、5ヶ以上の
データに対処してないというからには、そこまで厳密に作られていない気がする)
https://www.latest-info-system.com/ ここで全般のタブクリックして
『 Accessで起動オプションを省略する方法 〜Shift起動〜 』 というタイトルを探すと図解入りで
説明してくれてる その他諸々、Accessの説明してくれてるから参考までに
書いてるうちになんとなくマクロかな？と思い始めてきたが、その場合は、上記の手順で起動した時に
画面左のナビゲーションバーにマクロのカテゴリで項目が載ってるはず
今現在運用中のファイルをダイレクトにいぢろうとは思わず、必ずコピーとかを作ってソッチで作業を
しなければいけない 元ファイルを壊したら業務に支障が出るので 日付と商品と売上のフィールドがあるんだけど、日付から任意の月のデータを抽出。
抽出した月から、商品をグループ化して売上の合計。ってクエリで可能？
①月で抽出するクエリ
②①のクエリから商品をグループ化して合計する集計クエリ
と思ったんだけど、①のクエリの抽出条件を、11月分とか12月分に毎回変更するのも面倒なんだけど、他に良い方法ってない？ 少しだけ入門サイトを見るのも大事
このやり方で質問の回答には成ると思うけど
https://officek.net/access/a-query/aq-total/aqt-monthly/
魔法使いのおば・・おねえさんのサイトは、バージョン古いけど考え方の参考にするには十分
http://www.mahoutsukaino.com/ac/ac2002/ac2002/sonota/kensaku/ken01.htm
各月はコンボボックス使うとかの方法もあるし、このサイトのHOMEから辿ればいろんな手立ての
ヒントが満載 人知れずスキルアップしておちんぎんUPも決して夢じゃない vbaでクエリから別のクエリを使う方法ってありますか？
パワークエリのような使い方を想定しています テーブルも別のクエリも同じ扱いじゃないの？
vbaに限らず 数万件件ぐらいのデータ（外部DB)から、ランダムに20件ほど取り出したい
できるだけ同値でも同一レコードの取得は避けたい
実際、同値なら重複しても見た目わからないけど、仕様的には問題あり
今のところ Rnd で乱数発生させて .Move で取り出して、取得カーソルを配列に溜めてチェックしてるが、遅すぎ
外部DB用のODBCも遅い
PCのスペックもWin11がやっと
何かスッキリするやり方はあるかな？
ちなみに正月にコード書いてる人、いる？ >>363
>>乱数発生
そりゃ遅くなって正解
どうせVBAで乱数発生させてるんでしょ
クエリー作って10個おきに取り出す方が楽だし速い >>361ですが
少し調べてみてビュー文があるというのを知りました
create viewのようなsqlはvbaで実行できますか？ SQLの本見ながらSQLとAccessとの対応関係を考えているのですが
こんなんであってます？
| AccessAPI | SQL種別 | SQL |
―――――――――――――――――――――――――――――――――― |
テーブル |SQLDDL | CREATE TABLE |
クエリ |SQLDDL | CREATE VIEW |
アクションクエリ |SQLDDL,SQLDML | CREATE TABLE,INSERT,UPDATE,DELETE | 本当にそれ必要？
パラメータの値変更ではダメなの？
単なるクエリなら文字列連結したSQL文字列を実行すればいい レポートに高画質なベクトル画像を埋め込まなくてはならなくて、Access2000とIllustratorで作ったEPSファイルを使ってPostScriptプリンタで出力しているんですが、PSプリンタの選択肢が少なく先行きが怪しいので、SVGファイルを使って通常のプリンタから出力できないかと考えています。SVGをサポートして以降のAccessではEPSと遜色ないクオリティの出力を期待できますでしょうか?（wmfやemfはクオリティが低すぎて使い物になりません） Illustratorで作るなら今後はPDFファイルになると思うけど、古いAccess2000ではレポートにPDFを埋め込んだりファイル名のリンクでPDFファイルを入れ込んで印刷出来るかは知らない。
2000では多分無理だと思うけど、高い解像度の画像の入ったPDFファイルがその通りの高解像度で印刷できるか、最新のAccessはどうなのか自分も知りたい！
自分はAccess2010を使っているが解像度の高いJPG画像にしたとしても それほどキレイに印刷は出来ないように感じるけど、元画像を高解像度（350dpiとか）にしていないせいかもしれない。
Illustratorみたいなグラフィックソフトと違い、色彩も落ちると感じる。
グラフィック的なキレイな印刷に関してはFilemakerや、もしかしたらLibreOfficeのBaseより劣るかもしれない。 未登録状態でインストールして試してみたら、何とAccessはSVG未対応のようで、WordやExcelなどでしか貼り付けできない。一部のソフトでしか使えないのにあたかもoffice全体が対応しているかのような宣伝ってどうなんでしょうね。無駄な時間を取られてしまいました。 >>373
レポートやフォームのデザイン画面でレイアウトとしてレポートやフォームに画像を挿入する作業です。
AccessではSVGファイルは画像リストの候補になっておらず選択することができません。強引にSVGファイルを非連結オブジェクトとして貼り付けても何も表示されません。
エクセルやワードではSVGがリストに現れ、貼り付けて問題なく表示できます。
色々と試行錯誤してみて、AccessのレポートにPowerPointオブジェクトを貼り付けてそこにSVG画像を挿入したときにだけAccess上でもSVGが表示出来ましたがいかんせん作業性が悪すぎます。 あくまでも高画質なSVG画像が要求される → それを容易に扱えるアプリで対応
Access業務でレポートの一要素としてSVG画像が要求される → 已む無くPNG辺りに変換
365にしてもExcel･Word･Outlook･Powerpointにしか対応してないので、レポートを
それらのうちどれかに出力する工夫を試みる（Excelにテンプレートを用意して流し込む等）
無いものねだりして駄々捏ねてても捗らないことこの上無いし、生産性の阻害でしか無い
かねてより、ごく一部の機能に満足出来ずにAccessを貶める勢力はそれなりに居るが
所詮道具 すべてを満たす道具は古今東西存在しない その道具をいかに使いこなすか否か EPS画像という高品質なベクトル画像が使用できていたのに、それを使えなくした上でその代替手段となりうるSVGに対応しないというのだから個人的には明らかに機能劣化だと思いますが。
自分としては旧バージョンのAccessを使ってEPSとPostScriptプリンタで業務を続けるだけのことです。 それほど長い開発経験･運用実績あるなら、Accessの昨今の動向ぐらい把握してそうなものなのに
アプデもほぼ無くなってるし今後も改良･改善の見込み薄いし（枯れてるとも云えるが）
むしろこんなところで嫌味を書き殴ってるヒマあるなら、中の人向けに要望を出し続けてれば
そのうち向こうも発奮して「よし！SVGに対応だ！」に成るやも知れず
ところで、困ってる中身が未だに見えてこないけど、成果物としてのレポート上に高品質な画像
ファイルを貼り付けできない EPSやSVGでしか表現できない画像ファイルって何よ？
それは1ページにいくつ必要？ そうした画像を扱える他のアプリでは賄えない？
当初は社名欄に貼り付けるロゴ？とか予想してたけど、どうやらそういう類でも無さそうだし
ここまでこだわるからには、印刷屋並みのクオリティ求めてる様子だし、それAccessでやる？
という疑問が沸々湧いてきて仕方ない >>377
ペーパーレスが進むとPostScriptプリンタの先行きがどうなるかなと最近調べ始めただけの話です。
業務内容は人それぞれ。バリアブルの商業印刷なのでデータベースと連携が必要。4ptくらいの画像内文字も判別できないといけないので精査してAccessとEPSの組み合わせが最適解と判断。大量の画像、印刷枚数を扱うので高解像度のビットマップデータは容量的にも印刷速度的にも問題外。 やっぱりかあ それ、MacOS上でFileMakerPro と Adobe InDesign 連携させたりする奴じゃん
Access一本で賄う業務じゃあ無いケースだろ
そもそもフォームやレポート上で4ptフォントなんか、拡縮が貧弱なんだから向いてない(見えない)
校正も満足にできないアプリで成果物作り続ける方が、逆に相手に失礼なんじゃ？
ローン金利上がりそうだから急いでハードウェア＆ソフトウェア一式をリースで導入すべき
先行き心配してるンなら尚更今のうちに対策しとかないと、設備投資してじゃかすか顧客獲得してく
同業他社にお客さんを奪われちゃう 商売じゃ無くて自費出版とかなら知らんけど ですからね？今まではそれで出来てても、これから難儀な思いするって自分でも把握してんでしょ？
下請けとか外注とか他社との共同作業とかでも、おなじプラットフォームを要求されたり、連携時に
特殊な環境だったりするとハブられちゃう可能性だってあるでしょ？いいんですか？それでも？
この先ずっとSVGに対応してくれないAccessにつべこべグダグダ文句言ってて問題解決するんですか？
それでいいなら、今後このスレにまで出張ってきて嫌味タラタラ書き込まないようにしてくださいね
Accessってアプリは
表示(フォーム)や印刷(レポート)のカスタマイズが個人でも容易にできるように工夫された
入門用RDBMSってだけなんですから
DTP代わりに使いたいならそれなり制限の幅が多く成って当たり前ですよ 鉋で釘打ってるようなもん みなさんAccessと関係ない話になって来てしまってすみません。わたしはもうこれ以上書き込むことはありません。 長くAccess使っている人ならOSの対応など考えないわけはないだろうし、AdobeもAccessもOSも古いままネットワークから外して使い続ける場合もあるだろう。
周囲から批判されるのは確実だろうけど。
AccessとFilemaker使っているが、この話題に関しては確かにFilemakerの方が向いていると思う。
CADで書いた簡単な図面を入れるのを作ったことがあるけどAccessでは色々と厳しい。
でもAccessはバージョンが上がってもこれ以上のファイル対応や機能アップはしないと思う。それはFilemakerも同様。
イラストだけを印刷するのか他の項目と一緒にSVG画像も入れて印刷するのか判らないけど、PDFファイルのみならAccess VBAでファイル名からAcrobat-Reder起動して印刷させるとか、使ったことは無いので全く不明だけど Microsoft-VisioとかPublisherとかフリーのドローソフトへAccess VBAでアウトプットして高解像度印刷とか出来ないものかな？
もしDBとして簡単なら遊びのつもりで無料のLibreOfficeのBaceを試してはどうかな？ SVGファイルもPDFファイルもレポートに置ける。
PostScriptプリンタで文字のアウトライン化レベルの精密印刷が出来るか判らんけど、少なくともAccessよりは綺麗に印刷できると思うよ なんでまともにレポートを編集可能な状態でエクスポートできるのPDFだけなんだよ。
wordもっと頑張れよ。 手間を惜しまず、いまあるベストプラクティスを活用すべき
https://www.adobe.com/jp/acrobat/online/pdf-to-word.html
これを使ったからと言って、望む結果が得られるとは限らんが、もしお好みの結果では無かった場合は
PDFがベストプラクティスということ ありがとうございます。
でもACCESSでWORDに変換できずやるせない思いです。 >>386
表をWordで扱うこと自体が無理ないか？
Excelさえ満足に出力できないのに
うちはExcel出力自体ワークテーブルからの直出しで、好きに編集してもらうことになっている
今まではExcelオブジェクトでいろいろ編集してたけど、ユーザの欲しいフォーマットに毎回対応する工数の無駄だと理解してもらった
Wordで出したいってどういうニーズがよくわからん
出したいならWordのVBA操作しかないんじゃないの？ なるほど。wordで編集するってことがニーズがないのかもしれませんね。
印刷するときにExcelだと画面の表示と印刷結果が違ってくるのが気になってしまって。 教えてください。
部署内で業務管理･勤怠管理のためのシステムをACCESSで作りました。
このファイル内のテーブルを閲覧･編集をさせないためにパスワードをかけたいのですが、
ネットで調べたところ、accdbファイルのパスワードを解析するためのソフトがあることを知りました。
部署内にしつこく悪賢い人がいるのですが、そういう人が頑張っても解析できないようにしたいのですが、
パスワードを英数字記号だけではなく漢字も使ったものにしようと思ってるのですが、この方法は有効でしょうか？
他に何か方法はありますでしょうか？
PWを解析してテーブルを編集したがりそうな人は、おそらく3万円まではコストをかけるレベルで執念深い人です。
それともやはり、基本的に「アクセスファイルのパスワードに絶対破れないものはない」と考えるしかないのでしょうか？ ここで尋ねているということは、社内に同じ立場の人間が居ない？
上司上長と相談して、その開発システムでの運用の将来性について了解を得ておく必要もある
「そういう人」が頑張って解析できる余地を残しておかないと、万万が一の状況が起きた時に機能不全に陥る
他の誰もそのシステムを把握していなければ、ブラックボックスと化して誰もメンテナンスできなくなるし
データの復元やら移行やらすら不可能に成ってしまう （相談者が死んだりしたケースを想定
市販の業務･勤怠管理システムとかならサポートを受けられるので、多少の安心を得られる
FC2ブログなのでリンク面倒だから貼らないけど、hatenachipsさんの2012 04 05の記事が参考に成る
しかし「そういう人」ならこのスレも見てる可能性すらあるのでどうしたものか
データベース本来の運用に似せて、IDとパスワードでログインさせたりそのアクセス履歴を残すことで
セキュアにする方法もある >>390
金かけてまでパス調べるなんて暇人もいるもんだね
勤怠管理してるってことは給与に絡んでるからかな
iSunshareでもつかうのかね？
50桁ぐらいの大文字小文字数字記号混在のパスワードにする
コードとデータを分けて、データへきちんとID/パスワードをつける（Accessはできないんだっけ？）
キー以外は項目すべて暗号化する←絶対にやりたくない
万が一解析されてパス変更されたら業務に影響出るんじゃないか？ If おま死 then
社内阿鼻叫喚大混乱
Else
市販品導入
こうですか！？ わかりません＞＜ Access機能でなくともフリーソフトでファイルやフォルダを暗号化出来るソフトはいっぱいある。
ただ、そもそも社内データで見てはいけない社員がファイルをこっそり見ること自体が個人情報保護の面で問題ではないのか？ そのAccessファイルがサーバーの共有フォルダにあるのか誰でも使えるPCに置いてあるのか判らないが、そのファイルを開く権限が無い社員が開こうとする行為自身を規制すべきでは？
雇用契約証書？とか委託業務契約証書？みたいな誓約書を書かせて、許可なくファイルにアクセスした時点で減給とか解雇すると脅すべきでは？ 
