Access総合相談所 28
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 27
http://mevius.5ch.net/test/read.cgi/bsoft/1424828244/ >>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＋１０CALで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は１ハードウェアサーバーに
１つの役割しかさせないというのが常識だそうで
sqlserver用に１台、認証サーバー（ActiveDirectory)に１台
共有フォルダ用に１台って、なんでユーザーのログイン管理の
ためだけに
１０人分で５０万円近い金はらわなきゃならんのか、いまだに
納得いかない。 >>151
といってもそんなもまもってる馬鹿いないよね？ >>152
大企業はサポート受ける手前守ってる
中小企業は知らん
Windows Server使うメリットは現在では少ない
Linux,MacOSサーバーで済む 1つのサーバーに複数の役割を持たせるのは別にライセンス違反ではないでしょ
それでサポート受けられなくなるとかあるの？ Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
DB更新にもウエイトとか入れないとダメなのか？
そんなシステムじゃクラサバで使えないと思うんだが >>156
>>Accessって、バックエンドのDBをリンクテーブルから直接更新するとおかしくなるよね
昔からね
リンクテーブルに更新かけるのは基本的にしない様にしてる
ODBC経由で更新かけると大概タイムアウトくらう >>156 やっぱりおたくも調子悪い？
２人くらいまでの同時更新なら壊れないんだけど
３人くらいになるともうだめ。
壊れにくい方法としては、オートナンバーやめて
インクリメントの覚書きテーブルから払い出させる方法。
最終的には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ではライフタイムがないので、そのまま残ります。
一時テーブルの使い道は色々あります。レポートの呼び出しの時に
先に対象レコードを１個だけに絞っておきたいときとか、
前後のクエリーがくどい記述になる時とか、
VPN経由で回線が細い場合にレコード１個分だけ引っ張って
ワークテーブルとして利用するなど。 中間テーブルとクエリーをどう活用するか
がAccessのキモ
FileMakerにはAccessのクエリーに相当するモノが無い
SELECT文をスクリプトとして実行するか、テーブルオカレンスを使う
帳票ツールとして見た場合、Accessの方が安くて応用が効く
FileMakerはデータ保持容量の大きさとクエリー、VBAを使いこなせ無い人向けのDB(WebやiOSデバイスとの連携もメリット有るが)
何にせよFileMakerのライセンス料金の高さは中小企業には厳しいレベル 中小企業でFileMaker使ってる所は今後厳しいだろうね
ランニングコスト考えたらMariaDBやPostgreSQLとAccessの組み合わせの方に分が有る
OpenOffice BASEも有るし
iOSデバイス使ってないならFileMaker使うアドバンスは無い >>169
SELECT * INTO [EXCEL(バージョン) ;Database= (ファイルパス) 〜
とかで、１ブック内に複数の新規別シートで出力する時にも使えるよ。 いろいろレスありがとうございます
ビュー＝クリエは目からうろこでした
レスを元にいろいろ調べながら考えてみましたが中間テーブルを作るということはクエリと違ってSQL文を実行する手間が省けるわけでデータが大きくなるのに比例して演算時間の短縮効果が大きくなるのかなと思いました。 >>183
まだSharpポケコンPC-1480Uが現役なので、次はシグマリオンに機種変更します。 昔はレプリケーションとかWebコンポーネントとかpdfのコントロールとかあったのに滅びたの代替できるのないの 質問です。
AccessでUnicode文字を扱うにはどうしたらよいのでしょうか？
立方メートルの記号である㎥など、Unicode文字を扱いたいのですが、イミディエイトウインドウでもメッセージボックスでも ? になってしまいます。
イミディエイトウインドウで ?MsgBox(ChrW(&H33A5)) とやっても同様です。
何か方法があるのでしょうか？ >>186 の環境は Access 2013 です。 【 システム環境 】 Windows10, Access2010
お願いします。
データは入ってなくてもテーブルでフィールドを用意するだけでサイズは大きくなってしまうのか、
という疑問を持っています。
たとえば、家族テーブルというのを作るとして、
１レコードに、世帯主、家族１、家族２〜家族6までのフィールド構成にする場合と、
１レコードに、家庭id、家族内番号、名前、というフィールド構成にする場合、
どちらがＰＣに負担がないのか、ということです。
夫婦だけとか一人暮しの人も多いので、前者の構成だと空白だらけになります。ほとんどのレコードでは
データを入れる機会がないのにフィールドだけ6人分も用意するのはもったいない気もします。
しかし、後者だと、一人１レコードなのでレコード数が多くなるし、家庭idで複数レコードを
引っ張ってきて家族内番号で並び替えたりする処理なんかだと、かえってＰＣに負担かな、と
思ったりとか。。
一般論ですが、こういうの、どんなもんでしょうか？ Docmd.applyfilterで急にエラーが出始めた。
strFilter="Replace([col1],'hoge','fuga')…のところがエラーになるようになった。
昔はreplace関数でエラーになったが､ある日実験していたら､なぜか急に使えるようになったので､そのまま使い続けていたら､急にエラーが出るようになった。
なんで突然挙動が変わるのでしょうかね？ >>186
Access と VBA は Unicode に対応していますが
開発環境(VBE)とメッセージボックスは Unicode に対応していません
・Unicode 対応版のメッセージボックス(API)で表示
・メッセージ用のフォームを作成して表示
こういった方法になります >>188
1テーブルもアリです。10くらい作っておけば十分でしょう。
家族の名前を検索することもないでしょうし。
せいぜい法定福利関係のレポートに印刷するのに使うくらいでしょ。
もし、年齢が扶養家族に適合するか、みたいな属性もたせるのであれば分けた方がいいかもしれません。 >>188
家族の情報が、１人あたり大量にあったり、フリーテキストでもあるなら各１レコード持つべきだと思います
名前ぐらい、または続柄・生年・性別ぐらいまでの場合
自分だったら１つのフィールドを可変長文字列とし","で区切って入れて利用します。
家族無しならデータ長0のみになる
田中 トメ,田中 花子,田中 乱出威 妻,子,子。 yyyy/mm/dd,yyyy/mm/dd,yyyy/mm/dd, F,F,M など 最近はkintoneなどリレーショナルではないSaaSが台頭してきていて、
そのうち在宅ワーク（ないし出張先）可能とするニーズが出てくると思うんですね。
そうなるとAccess使いにはちょっと心地悪いんだけど、なるべく1テーブルに収める設計にシフトすることになるかもしれません。 >>191
そうだったのですね。
ありがとうございました。 MSがAccessやめてシェアポイント使えって言い出して長いからな
そのうちpythonで開発するように 昔自分で作ったけど、もう古いし欠陥も多いツール
もうおススメしない言ってるのに、
周りは慣れてるし実用に耐えるし便利だと言い使い続けて
たまに問い合わせしてくる
とか、クリエイターは嬉しいような困ったような >>196
>>シェアポイント
ユーザー増えないのは、問題有るからと過去の資産が有るからね >>196
Visual Studio LightSwitchの事もたまには思い出して 小さいオフィスで自分ひとりでACCESSつかってて
大して作業規模はかわらないけど別の営業所ができた場合（そこでもなんらかの入力をする）
一般的にはどのようにしているのですか？
リアルタイムでデータがいるわけではない場合、
別個にファイルを用意して、都度統合させる感じでしょうか？ >>200
テーブル部分をNASに置いてvpnやってみたけど、けっこうきつい。回線品質は悪いときで3Mbps。
しかたないのでDBサーバー立ててadoでチビチビひっぱるリビルドでだいぶよくなったけど、
コードをトータル1000行くらいは書いたんじゃないかな。
必要な工数が格段に増える。
おっしゃるようなやり方は矛盾生じるのであまり良い設計ではないかもしれない。
スマホのアプリ、特に5ちゃんねるブラウザはSQLITEでキャッシュすることが多いので、そういう方法論が参考になるかと。 >>203
別拠点はむずかしいんですね
一般的な零細はどうやってるんですか？
営業所ごとにスタンドアロンなんですかね？ FAXかな
ま、戯言はともかく、ルール作りが肝心
各拠点は何を必要とするか 本部はどの頻度でデータが欲しいか 次第
双方がリアルタイムで生の情報を必要とするなら相当工数も費用も必要となるし
終業時に一回送信すればいい とかなら該当データをメール添付で送受信するだけでいい
その場合はデータのインポート・エクスポート工夫するだけで済む
調子こいて大手の真似してVPN とか、できる。ってだけで実用に耐えない
便利を求めて本末転倒のアリ地獄
そういや出来立ての頃のFAXって、ハガキサイズ送信に5分ぐらい掛かったな
受信はその2〜3倍掛かってたような >>205
基本的には出勤簿とか売上データくらいだから
まあメールのインポートで大丈夫そうですね
双方で同期するようにしなくちゃいけないから大変そうですけどね
どちらもファイルを別ファイルにしてクラウドにおいておいて、一日のはじめのACCESS起動時に相互にインポートするようにしたらいいのかな >>206
それ、簡単そうに見えて結構大変よ。
多拠点のすべてのテーブルの追加 修正 削除の履歴を集め、
どの修正が優先されるのか検討しなきゃならんから。
A拠点がレコードID10を追加しました。
B拠点がレコードID10を追加しました。
A拠点がレコードID3を修正しました。
B拠点がレコードID3を修正しました。
A拠点がマスター系レコード1を削除しました。
B拠点がマスター系レコード1を参照する実績系レコード1を作成しました。
→翌朝に同期
シス管がいない程度の会社であれば、両拠点でヤマハのルータ（2万円の中古でもよい）を買えば、無料でvpnサービスを使えます。
まずは共有フォルダー上にテーブル用ファイルを置き、
単純なリンクテーブルでいけるか試してみては？ >>200
自分ならPHPとかで作り直しますね。
どうしてもAccessじゃなきゃダメなら別ですが、色々考えるとWebに出した方が結局ラク。 ■ このスレッドは過去ログ倉庫に格納されています
