Access総合相談所 27 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
ACCESSに関する質問はこちらへ
▼━ 質問のしかた ━━━━━━━━━━━━━━━━━━━━
★ OS、ACCESSのバージョンを明記してください。
★ 質問内容は具体的に書いてください。
・何がしたいのか
・どんな処理を試したか
・動作状況など駄目な理由
テーブル/フォームの構成、クエリ、VBAの内容など差し支えない
範囲で詳しく書くと、早く回答が得られるかもしれません。
図解があれば尚良し。
聞き返さなくても詳細が把握できる質問が望ましいです。
★ 事前にヘルプ・Google等で調べられる範囲は調べてください。
大概の疑問は検索することで解決します。
★ アドバイスを貰ったら、必ず経過・結果の報告をして下さい。
ギブアンドテイクで情報を共有しましょう。
▼━質問テンプレ ━━━━━━━━━━━━━━━━━
【 システム環境 】 Windows**, Access**
【 VBAが使えるか 】 はい･いいえ
【 VBAでの回答 】 可･否
【 検索キーワード 】 Googleやヘルプでの検索キーワード
前スレ
Access総合相談所 26
http://toro.2ch.net/test/read.cgi/bsoft/1349049986/ >>83
exactly
あとは、両者を一覧で見る為にユーザマスタIDを基準にクエリつくっておけば
いいだけ。 家族経営の会社やってます
ExcelVBAでやってましたがデータ量の増加によりAccessへの移行を考えています
基本的な売上入力から請求などはある程度かたまったのですが
会計処理(いままではアナログ管理)は同じシステムに組み込んでもいいのでしょうか？
諸経費テーブル、ローン返済テーブル、借入金テーブルなどをつくるということです
決算書は税理士委託のため細かい会計自体が委託になっているので資金繰りのときの資料として利用したいです 【 現在使用のシステム環境 】 WindowsXP, Access2003
【 今後使用予定のシステム環境 】 Windows8.1, Access2013
【 VBAが使えるか 】 はい
【 VBAでの回答 】 可
アクセスから離れて久しいのですが、
以前2003のADP形式で作ったSQLサーバーとのシステムがありまして、
今度システム入れ替えで2013にするのですが、
確認テストの段階で2013ではADPファイルが変換も開く事もできません。
2013からADPは無くなったのでしょうか？
あともうすぐ2016？が出ると聞いたのですが、
この2016もやはりADPファイルを扱えないのでしょうか？ >>86
何を今更・・・・
2010からなくなってるよ。調べりゃ分かることだろ。 >>87
ありがとうございます。
2013からなくなっているようですね。
これだと2016？も多分ないのでしょうね。
2010もしくはODBC接続での変更やVBでの検討をする予定です。 Accessが根本的にわかりません。
どうしたらいいですか？
というのもテーブルの設計とリレーションシップの設計ができません。
最終的に何がやりたいからこのテーブルのこのフィールドとあのテーブルのフィールドをリレーションするとか
そういうのがわからないんです。 >>90
そりゃ困ったね。
学生名簿と試験成績表、社員名簿と出退勤記録、顧客一覧と購入履歴など、身の回りの既にあるデータをテーブルにするところから始めては？ >>90
なら、例題を与えよう。
一番身近で自分でも使うものだ。それは、家計簿。これが一番シンプルで最も
わかりやすい。辺に業務知識を要求しないしね。
で、Accessを挫折する奴の大半がその第一の壁で躓くんだよ。
最初にやる事は、勘定科目のテーブルを作ること。次に記録を取るテーブルを
作ることからだ。そして、勘定科目のIDと記録を取るテーブルの勘定科目の列
とをリレーションシップを貼る。 >>93
一般常識ないのなら、それはAccess以前の問題だよ。 家計簿の場合勘定科目というほどのものはいらないんじゃない？ >>91
まさにそれですね。
自分が作りたいものは顧客一覧と、購入履歴を1つのフォームで管理するデータベースです。
そもそもリレーションの貼り方がいまいち分からないんですよね。
リレーションシップというアイコンをクリックしてそこから作ればよいのですよね？
例えば、テーブルAのフィールドAからテーブルBのBフィールドに向けて引っ張るだけでよいのでしょうか？
ここで引っ張る方向を間違えると一体多の関係が逆になっちゃうなんて事になるので、
どっちが一でどっちが多なのかの関係を理解する必要がありますね。
>>92
本当は>>91に書いてるように顧客一覧と購入履歴のデータベースが作りたいんですが、
まずは家計簿がよいでしょうか？ >>96
引っ張った線を上手く右クリックして調整できるよ。 >>96です
このようなものを作るのに参考になるサイトはありませんでしょうか？
顧客一覧と購入履歴を管理するデータベースを一から作ろう！(初心者実践編)みたいな。 >>98
普通に本を１冊買ったほうがじっくりスキルを身につけられるよ。
ウェブでバラバラと知識を手に入れるよりもね。但し、以下の本は除く
１．できるシリーズ
２．逆引きシリーズ
ただし、自分に合うものはよく読まないと無駄になってしまうので、
じっくり本屋で立ち読みして買うと良い。
そこから先は、ウェブのほうが実践スキルを身につけられるから本じゃ全く
力不足になるが。
※ちなみに俺はほとんど独学だが、買って勉強した本は１冊だけある。それは
http://www.scc-kk.co.jp/scc-books/support/B-102/support.html
自分が会計ソフトを作る必要があったので、参考になった。これをベースに、
経営シミュレーションを作った。 >>99
やっぱり基本を押さえないことにはどうにもなりませんね。
できるシリーズ以外で
自分なりにも調べて古本ですが、かんたん図解(基本操作)、プロパティ辞典、Accessデータベース理論があったので
買ってみました。 Accessデータベース理論を最初から熟読中です。
(Accessの基本操作ではなく理論の方)
これしっかり読み終わらないと、作りたいものがあってもいきなり手を出すのはやめた方がいいですよね？
急がば回れの精神で読み終わるまで。
基礎が固まってない→テーブル設計がめちゃくちゃになる→結局つくれないことに。 >>103
別にやりながらでいいと思うけれど。
基礎って結局の所、１発で頭に身につくわけがないから、トライ＆エラーで
本見ながら作るほうが近道。
結局作れないなんて 当たり前のこと なので、その都度その都度なぜ、
おかしくなったのかのトラブルシューティングで根気よくやると、ある日突然
アハ体験が来る。
これが出来るか出来ないかが習得の分かれ目。Excel組が挫折するのは、
こういうのが出来ない人ばかりだから。結局身につけてしまうと、大したことじゃ
ないんだけれどね。
それを補強するのが、データベース理論本と言える。 理論なんて知らん。見よう見まね。
まあ利用者はたまったもんじゃないだろうけど。 いくら見よう見まねって言っても
理論が分からないと作りたいもののテーブル設計とかリレーションとかできなくない？
これを実現するにはどうやればいいんだってならない？ 何を以てして基礎をマスターしたと断言するのか
オラクルマスター？ テーブルの分類分けができません。多分頭が悪いんだと思います。
どういう事かと申しますと
商品テーブルに仕入先フィールドを設けるべきなのか
仕入先テーブルを別に作るべきなのかといった具合です。
最終的に何がやりたいからこのようにテーブルを分けるべきだというテーブル設計が難しいです。 accessで売上の入力やそれにかかった経費(従業員や営業車の維持費)などを入力するものをつくろうと思っています
会計処理というか金の流れを把握するために帳簿をつける場合
入力された売上などを集計し、別途弥生会計などのソフトに入力するのでしょうか？
それともうまい具合にエクスポートインポートできるのでしょうか >>110
売上の入力がいろいろ複雑な計算があったりそれを元に請求書つくったり
従業員への歩合もあるので
市販ソフトでは対応できそうにないんですよね >>111
弥生、いろいろできるけどなあ。法改正も対応してくれるし。自作は法改正対応を自分でやることになるよ。
別にとめないけどね。 >>112
さすがに在庫管理したり販売管理したり給与管理するには弥生会計だけじゃむりじゃないの？
市販の販売管理なんかも細かいとこでなかなか自社にあった構造になってなかったりするし
そこいらはAccessやExcelで自作して
弥生に出力するもゆじゃないの？ そも、弥生は手持ちであるのか無いのか
有るとして、入力の前段階をＡｃｃｅｓｓなりＥｘｃｅｌなりで下拵えだけしたいのか
としたら弥生側でインポートできる形式を把握して、その仕様に合わせる必要があるし
Ａｃｃｅｓｓから直接弥生にエクスポートは・・ 出来ないんじゃないかな
そんな仕様公開してないだろ、たぶん
無かったら自分の好き放題に作ればいいし
ただ、そんなとこで思案に暮れてるようじゃあ、二年掛けても完成は覚束無いんじゃ・・
その二年を生暖かい目で見てくれる環境なん？ 親が経営者とか？ その間の経費で外作に出したほうが 一般的には販売管理や売上管理に基づいて発行する請求書などと
会計は別だと思う
各部署や担当が入力集計したデータや請求書データを
会計担当に渡してそこが簿記などの会計処理する >>114
なら、お前は黙ってるといいよ。
お前の御託は誰も聞いてないｗｗ Accessのフォーム作成でお伺いしたいのですが
例えばコマンドボタンを置くと、名前が日本語で「コマンド～」になりますよね。
これを「Command～」みたいにデフォルトでアルファベット表記にすることはできませんか？ >>117
コントロールのデフォルト標題を設定するのは無理だと思うけどなあ。
一つ一つその都度変更していくしかないんじゃないかなと俺は思ってる。
そこらへん知りたいけどね >>117
vbaでコントロールの名前変えてる。
テキストをtextやリストボックスをlistにしてる。 アナログで考えてみたらいいと思うんだけど
何個仕入れて誰がどこに何個いくらで売ったか
というのを記録しておくノートがあり
それをみて帳簿に売掛いくらと記入するんだから
販売管理ソフトと会計ソフトは別だと思う >>115
各部署って個人事業主が使う機会が多いのにナニイッテンの？ >>121
そういう御託は他でやりな。スレ違いなんだよお前。 Accessのレポート機能での質問です。
A4サイズの「請求書」とその「控」を同時に印刷するため、
レポートの横サイズをA4サイズの2倍にし、控と請求書のコントロールを配置することで
印刷すると、1ページ目が「控」、2ページ目が「請求書」を印刷できるようにしています。
業務では1度に両方印刷するときもあれば、控だけ印刷するときもあります。
単発案件の印刷のときは、印刷プレビューで「1ページ目だけ印刷」とかすれば問題ないのですが
複数案件の時はそれができないので、何か解決法がないかと探しています。
印刷ボタンを押したときにinputboxで
「（1）請求書印刷」「（2）控印刷」「（3）両方印刷」
を選ばせ、（1）と（2）の時は印刷する範囲を横幅何cm～何cmまで
見たいな手法で解決することはできないものでしょうか？
または他のアイディアがあればぜひご教示願います。 補足
「請求書」と「控」には、後者に
「（控）を印字する」「日付を印字しない」という違いがあります。 自己解決しました。
レポートの「詳細」セクションに「請求書」と「控」を横並びさせるのではなく
サブレポートにして、
「控」をサブレポートのヘッターセクションに
「請求書」を詳細セクション
に配置換えし
印刷ボタンを押したときにinputbox関数で片方か両方印刷するか選ばせて
レポートの「グループヘッター」と「詳細」のフォーマットに
Me.グループヘッダー1.Visible = False
こんな感じで制御できました。
スレ汚しすいませんでした。 ありがちなのは「(控)」と日付を visible True/False でコントロールするとかだけど
正式が出力済み・控えのみ・・ などを管理したい場合は請求データにフィールド設けるとかしないと
「あ？どっち出したっけ？」になる
Ａ４サイズ縦を横並びに二枚 っつーとＡ３ヨコのレポート？
それぐらいならレポートを二つ作って方や正式、こなた控え で、どっちのレポートを出力・・と、分岐させる
手もあるだろうし 大きいレポートでてんやわんやするよかＡ４タテで統一しといたほうが手間が少ないような
ところで控えつうと、相手に正式/自社に保存する分が「控え」というケースが多いと思うけど、日付要らんの？
そういうのは「仮」扱いとかじゃ無いん？
あ、出力対象をワークテーブルに入れて(1)(2)のフィールド設けてチェックボックスとかで分別
１だけ ２だけ 両方チェックは・・ でレポートを選択させればいちばん楽か >>128
レスありがとうございます。
当初は
請求書も控もA4サイズで、印刷設定をA4にし、請求書が2ページ目にくるように微調整していました。
（これでは単体のみ印刷をする方法で行き詰ってしまったので、>>127 に変更しました。）
日付が空欄なのはお察しのように「仮扱い」の場合で、
この時は本番まで印刷する必要がないので、
「仮」だけを印刷できるように模索していた次第です。
本来は、ワークテーブルにデータを転送し、
それをデータソースにしたレポートにするべきだと思いますが
そこまで作りこんでいないのが現状です。 いや、データまるごとワークテーブル・・ は必要無くて 対象の得意先コード？ 番号？ と得意先名程度
それだけをワークに入れて実データとクエリやらで ・・でいいと思うけど
ワークに入れる理由は印刷チェックの(1)(2)を使うためだけ
そのワークをソースにしたフォームでチェックOn/Off入れて、印刷の判断基準にすると 印刷終えたらワーク消すなりなんなり
(1)Onグループは正式レポート (2)Onグループは仮レポート（つうかVisible True/False か) 両方Onなら両方出力になるし >>124←現場をわかってない馬鹿はこういう見当違いなレスをする。 >>132
そもそも、小規模な企業組織では総務経理などは兼務が当たり前で別れてない
ので、「使う」などと言った所で、>>115を覆す理屈にはならんってこと。
請求書と会計が別なんて、それなりの規模の企業で言うべき話であって、小規模
な利用が当たり前のAccessスレで>>115みたいなマヌケな そして誰もが知ってる
話など、見当違いも甚だしいってこと。
ま、大規模企業ではそもそも別なんてやってないけれどね。 最新バージョンのAccess2010でなければならないものってどんなものがありますか？
よほど特殊な要求がない限り最新機能なんて使わなくてもそこそこやりたいことはできますよね？
うちの会社のシステムはこういうものが必要だったからそれはAccess2010じゃないと出来ないとかあったら教えてください。 まだ初学段階なのでこれから作ろうとするもの対して
それがどのバージョンでなければ作れないなど、バージョンごとの機能知識はありません
まだそこまで考える知識は身についていません。 女子中学生が学友を金槌とのこぎりで解剖した。
鈍器で後頭部を殴り、体を切断、腹を切り裂き、内蔵を取り出す猟奇的犯罪。
加害者Y子【ザキシマ結子=元稲城市立向陽台小学校評判Y子】の家庭環境、
小学生、中学生時代の壮絶な問題行動が明らかに。
給食へ漂白剤等異物混入、猫の殺害解剖、実兄(嶋崎亮介(TDU万引少年S東京電機大学中学校評判落とす万引少年S君)
父親嶋崎慎太郎（近○相姦←結子と）自殺。 >>133
じゃあAccessやExcelで売上管理してるとこは
帳簿つけるときに弥生会計とかつかってないの？ >>133
文章が下手くそすぎていってる意味がわからん >>135
ネットワークにオンラインなら新しいに越したことは無い(セキュア的な意味で)
オフライン、スタンドアロンとかなら現場ではAc'97だろうといまだ現役で普通に稼動させてたりする
機能的にはAc'97やら2Kやらの頃は「頑張れば自作できる」ものが最新のは標準で装備されてたりとか
逆にカレンダとかツリービューとか便利だったものがダメ出しされて消えてったり(頑張ればつくれるけど
あるいはカタチを変えて新登場) とかとか 熱意があれば努力量はおんなじかも 見た目が「古臭っ！」て言われるかも、もあるか >>137-138
相手にしない方がいい人じゃないかな。
現場のことは誰かに聞いた話だけで妄想してるんでしょ。
先さんなんて規模も思考も千差万別だから何でもあるんだよ。
無いのは予算と仕様書だけ。 >>115
普通は連携させるんで、会計担当がそれらの会計処理なんて
やりませんよｗｗｗ
更に言えば、小企業の場合、その手の処理は一人で担当するので、
会計と売上が別部署でそれぞれやるなんてやりません。
売伝上がってる段階で既にもう会計処理は終わってますよ。
会計というか経理が何やってるか知らんらしいね。君。 >>141
個人経営レベルの人がつくったAccessでそこまでできると思ってんの？
自分にあったExcelを発展させた販売管理をAccessでやって
請求書などを発行してそれを会計ソフトに入力して帳簿つけるんだと思っけどな もっというと
Accessでつけた集計された売上をもとに資金繰り表などをつくると思うんだけどな 個人的なスキルアップのためにMOSのAccess(一般)を受けようかなと思ってますが
どうでしょうか？
転職や就職で履歴書に書いて面接で少しでも評価をもらうという気はさらさらないんですが、
試験勉強するだけでもAccessのスキルは身につきますか？
あんまり意味ないでしょうか？ >>144
全く意味が無いということを保証する。
この手のソフトウェアは実践に勝るトレーニングはない。
そしてそれら厳しい実践 つまり実務でつきつけられる課題
があるから必死に取り組む。そして身につく。さらに言えば
VBAはプログラミングスキルそのもの。
本なんか読んでも１行もコードは書けないよ。 全く意味が無いかはわかん無いけど、求められてると上達するよ。こんな風に見せたい、少ないクリックで目的の情報まで辿り着かせたいとか工夫すると。 >>145>>146
ありがとうございます。
MOSは意味がなさそうなので受けないことにします。
実務でやるのではないのですが個人的な目的で作りたいものがあるので
基礎があまりないですがいきなり実践で取り組もうと思います。 >>147
都度都度壁が出てくるだろうが、それらを１個１個調べて、クリアして
行く。これが王道。
その内、それらは壁でなくなる。アハ体験が来たらひとつのゴールだ。 >>8
無くなるの？
今から勉強しようと思ってたのに、うわぁぁ access2016はプレビュー版にあるから大丈夫じゃない？ Access初心者で勉強していて少し気になったことがあるので質問させていただきます。
ルックアップフィールドのプロパティで「値集合ソースの値のみの表示」っていうのがありますが、この意味を調べると、
「”複数の値の許可”が”はい”に設定されている場合、現在の値集合ソースに一致する値のみを表示します。」ということですが、
値集合ソースにない値がルックアップ列に表示されるってことがあるのですか？ 【 システム環境 】 Windows8.1, Access2007
【 VBAが使えるか 】 はい
【 VBAでの回答 】 可
【 検索キーワード 】 Access2007 タッチキーボード 表示
フォームのテキストボックスがアクティブになった時に、
Windows8.1のタッチキーボードを自動的に表示させる方法ありますか？
できれば数字入力状態で表示させたいのですが。 >>153
そんな機能は存在しませんよ。
そもそも、Accessはタッチパネル非対応です。 >>153
その機能、私も欲しいです。なんかやり方有りそうですよね。 Access自体がなくなる方向だからこのスレもそのうち終了
今のうちにＶＢやＣ＃習得したほうがいいよ >>156
VBだのVC#だのやるくらいなら、HTML5 + CSS + JavaScriptのほうが
何倍もマシだよ。そっちのほうが乗り換えし易いし。
現実俺は、Accessの次として乗り換えて、サーバサイドはNode.jsを使って
今まで作ってきたヤツを移植してる。 >>156
今更、.netなんて一番選択肢としてあり得ないわけだがｗｗ
別にプログラム組みやすいわけでもなんでもないのに。
おまけに最も重要なレポート機能がない。あっても、アレじゃなｗｗｗｗ
今更ローカルアプリってのも進歩のない話だわ。 組みやすいかどうかだけで言えば HTML5 + CSS + JavaScript は到底組みやすいとは言えんけど。 [やりたいこと]
1つのフォームに顧客情報と、サブフォームに納品履歴を表示させるようなものを練習で作ろうとしています。
テーブル設計がそもそも出来ていないか、テーブルの主キーの使い方が駄目なのかな？
と思ってはいますが、どのようなテーブル設計にすればうまくいくでしょうか？
[仕入先テーブル]の会社名フィールドから、[納品履歴テーブル]の仕入先フィールドに引っ張ってリレーショナルを作ろうとしたら
型が違うのでできません。
同様に、[納品履歴テーブル]の納品先フィールドと[顧客テーブル]の氏名をリレーショナルを作ろうとしても型が違うのでできません。
[顧客テーブル]
顧客ID(主キー)・・・オートナンバー型
氏名・・・テキスト型
住所・・・テキスト型
[納品履歴テーブル]
納品ID(主キー)・・・オートナンバー型
納品先・・・テキスト型
日付・・・日付型
商品・・・テキスト型
仕入先・・テキスト型
[仕入先テーブル]
仕入先ID(主キー)・・・オートナンバー型
会社名・・・テキスト型 >>160の補足
各テーブルには他にもフィールドが有りますが、
質問とは関係がないと思われるフィールドなので省略しています。 すみませんリレーショナルではなくリレーションシップです >>160のリレーションの部分の訂正です。。
[仕入先テーブル]の仕入先IDフィールドから、[納品履歴テーブル]の仕入先フィールドに引っ張ってリレーションを作ろうとしたら
型が違うのでできません。
同様に、[納品履歴テーブル]の納品先フィールドから[顧客テーブル]の顧客IDフィールドに引っ張ってリレーションを作ろうとしても型が違うのでできません。 >>160
[納品履歴テーブル]の[納品先]と[仕入先]をテキスト型から数値型に変更してみてください。
オートナンバー型は長整数型です。
サブフォームについてはサブフォームのプロパティの
リンク親フィールドを[顧客ID]
リンク子フィールドを[納品先]
に設定します。
リレーションシップは作成しなくても型があっていればリンクはできるはずです。 >>164
なるほどです。テキスト型だからいけないのですね。
サブフォームってリレーションシップとは関係のないものなんですね。
今回作ろうとしているサブフォームの目的を達成するには、リレーションシップを作成しないといけないものだと思っていました。
リレーションシップを作成する意味が理解出来ていないようです。 Accessの本に、Format関数の例として
①Format("2013年8月1日",yyyy/mm/dd) →2013/08/01
②Format(21,"00""日は休館日です"""） →21日は休館日です
と書いてあるんですが、
①について、「2013年8月1日」を「"」で囲っているのは、2013年8月1日は文字列としてAccessでは解釈されるからですか？
Excelで2013年8月1日と入力すると数値と解釈されますが、Excelとはまた違うのですか？
②について、「日は休館日です」というところを、「"」２つで囲っているのはなぜですか？
つまり、「"00"日は休館日です""」とならないのはなぜですか？ ①文字列を指定しているから。
②ダブルクォーテーション自体を文字列として扱うにはダブルクォーテーションを2つ指定する。
"を指定するには """"
A"Aを指定するには "A""A" Windows7、Access2010です。
【構成】
・クライアント側
・Access2010 Runtimeがインストールされています。
・mdb・・・VBA、フォーム、レポート、一時テーブル
・サーバー側
・Access2010がインストールされています。
・mdb・・・「商品マスタ」（リンクテーブル）（1万レコード）
「商品マスタ」から「品名＝りんご」のデータをフォームに表示するとき、
rs.open "商品マスタ"・・・
rs.find "品名='りんご'"・・・
のやり方だと、普通にJETの仕様としてLAN上を1万件のデータが流れてしまうかと思います。
ここを改善できないものかと考えているのですが、例えば
strSQL="select * from 商品マスタ where 品名='りんご';"・・・
rs.open strSQL・・・
とやれば、サーバー側のJETで処理されて結果だけが返ってくるようになりますでしょうか？
また、これでもやっぱり1万件全部ローカルに持ってきてしまうという場合、
サーバー側mdbをSQLServerにすれば、結果だけが返ってくるようになりますでしょうか？
よろしくお願いいたします。 サーバ側でデータベースサーバが動いてないと検索結果だけを取ってくることはできないだろjk
でsqlserverならどうかっていうと望み通りのことができるよ。他のでもいいけどね。 >>168
サーバーにテーブルだけのmdb置いて、クライアントのmdbからリンクする。
SQL Server無くても想像以上に軽快だと思う。
レスポンスに満足できなければバックエンドをSQL Serverとかで。 >>171
現在のAccessは複数クライアントをLAN経由接続しても大丈夫なんだな。
昔じゃ考えられない事だ。 >>170
DatePart使えばいいでしょ。
つーか知恵遅れって解答が制限されていたりするから、面倒だよね。
普通にVBA 週 取得とか調べれば出てくるたぐいのものなんだがなぁ。 >>170
1ヶ月が4週と自分勝手な仮定がイタすぎる。
どこの惑星に住んでんだ。
で、DateAddを使えばよいって、それは質問者も書いてるだろ。
>>173
意外と正しく求めるのはめんどくさいぞ。 >>169、>>171-172
ありがとうございます。
ちょっと仕組みがよく分からないのですが、
strSQL="select * from 商品マスタ where 品名='りんご';"・・・
rs.open strSQL・・・
という書き方にすれば、select文の結果しかOpenしないように感じるんですが、
「単にテーブル丸ごとOpenしなくなるだけで、データは丸ごと持ってきている」ということでしょうか？
（メモリ使用量（？）が減るだけで、肝心のLANのトラフィック（？）は減らない？） トラフィックがどうの、はわからない。
サーバー側のaccessは要らない。
一万件でレスポンスが問題になるとは思えないが環境が違うからなんとも。 >>172
最近のAccessはよく知らないから俺もそこ気になる。
2007からのaccdbなんかだと複数リンクでも壊れにくいのかなあ。 2002の頃からその使い方だけど一度も壊れない。確かその頃から分割ウィザードってあった気がする。 ただ、テーブルのみmdbのLAN経由複数クライアントリンクだと
処理がめちゃくちゃ遅くなるよ >>179
Windows2003Serverにテーブルmdbを置いてクライアントから
リンクした時にめちゃくちゃ遅くなる症状出たけど、2008R2Serverに
置いたら普通に動くようになったよ。 >>176-181
勉強になります。>>168です。
私は、>>168に書いた環境でクライアント側は20～30台で、全てRuntime2010、フォームは全て非連結、
サーバー側mdbは100MBくらいでリンクテーブルでアクセスする形ですが、
ファイルが壊れるようなことも無く、安定して運用できています。
2003の頃の名残でmdbですが、2007以降のaccdbでもたぶん同じじゃないかと思います。
ですが、これは「同じ建物」内の話でして・・・他の営業所などの遠隔地からアクセスすると、
>>179さんおっしゃるように、とてつもなく遅くなります。
対象テーブルの全レコードを持ってきてるんだから当たり前の話なんですが、
普段なら一瞬生成されてすぐ消えるldbファイルが、
遠隔地からのアクセスがあると1分以上も生成されっぱなしの状態になりｗ、
その間に他のPCからのアクセスがあるともう強制終了となり、最悪ファイルが壊れることもあります。
ファイルが壊れるのは、素人なので排他制御がちゃんとできていないのかもしれませんが、
Accessの大前提である「全レコードを持ってくる」というのがもうダメだなという感じ。
手っ取り早くレスポンスを向上させるには、やはりサーバー側mdbのSQLServer化がベストっぽいですね。 自分も、2MB程度のデータ部とをLAN上のPCでリンクしてつかっていますが
LAN上のフロントエンド部からデータ部をアクセスすると処理がえらく重くなりますね。
まぁ、これはAccessのデータ部にSQLServerのデータをリンクテーブルでつないでいることが影響しているのですが
ただ、運用してもう3年たちますが、破損したことはないですね。 ■ このスレッドは過去ログ倉庫に格納されています
