何度も挫折するアクセスの勉強法？
けれど、データベースソフトのアクセスは、何度勉強しても途中で訳が
分からなくなったり、飽きてしまったりし、実務的にデータ管理をした
いにもかかわらず、ついつい表計算ソフトのエクセルで間に合わせてし
まいます。
良い、上達法、勉強法を皆さんの経験から教えてください。
そうすればRDBの意味が分かる。
ACCESSのクエリーとかはちょっと癖が強いから挫折するんだよ。
素直にSQLあたりから始めなされ。
鉛筆もって、ノートに書いてろ。
訳がわからないのは頭が悪いだけだからさ。
実際半分の人は平均以下な訳だし。
そのＨＰ見て、それでも挫折するなら、諦めなされ｡
ファイルメーカーにしたら？。
今ではこれ無しで仕事なんて考えられません。
っつってんのに何が
＞ＡＣＣＥＳＳ＋ＶＢＡ超便利！
＞今ではこれ無しで仕事なんて考えられません。
だよ。
これじゃ「豚肉超うまい！今ではこれ無しでは夕食なんて
考えられません。」とかいってるの変わんないじゃん。
そんなお前の意見なんて誰も聞きたくないっつの。
R。
あんた、いいこと言うね！
あんたみたいな人が、この日本を住みやすくするに違いない！
なにか、修行された方？
おらは、ソープランドでテクの修行中！
従業員を無理なくカット！
漏れもＸ−ｍｅｄｉａ社の超図解シリーズのＡＣＣＥＳＳ ２０００基礎編
を買ってきたので勉強する予定です。クエリ＆上級編も出版されてます。
ただ、問題は会社がＡＣＣＥＳＳ９７なので、自宅のＰＣに２０００を入れて
勉強するしかないかも。
>暇なときにこつこつとマイペースで勉強すればいいのでは？
こんな考えじゃやるだけ無駄
漏れは2ヶ月でシステム作れとかいわれて、ボロボロになりながら
覚えたもんなぁ・・・でも今ではそれが生きている（藁
エクセルトの連携もばっちりだし。アクセスより効率良くて合理的。
ファイルメーカーに一票
FileMakerに一票。
>ロータスアプローチつかってみ
却下
本も入手出来ない、聞こうにも知ってるやつは誰もいない
そんなものは使わないほうが幸せ。
どんなもの作ろう？では無くて、自分に何が必要か？これが大事。
そうでないと、どのDBMSも理解は困難。
とどのつまり、最初の内はどれも一緒！
理解が深まると色々な差異が分かってくる。
設計も個々で色々変わってくるしね…
何を作りたいのか？何が必要か考えるべし！
それほどのデータ量じゃないんでしょ？
人によるでしょうが、
自分なんか、どうしてもやらきゃならないことになり、
尻に火が着かないとダメなタイプなもんで。
いつまでに、どこまでを、やらざるをえないとなったら
徹夜とか、土日なしとか、せっぱ詰まってやると
身に付くと思いますよ。
その最中は、シンドクてブン投げたくなるけどね。
確かにね、それで何とかなってるなら、
無理しないで、今までどおりにしていくのが一番かもね。
２日間くらいの初級、応用のセミナーは受講したので。
無謀でしょうか。
使い方なんぞ、ネットで探せばいくらでもあるぞ。
日本実業出版社「図解でわかる データベースのすべて」
ttp://www.njg.co.jp/c/zukai.htm
ＳＱＬについての本も。
翔泳社「初心者のためのSQL入門１−はじめてのデータベース操作」
Accessは、RDBMを実現するための一ソフト。（ApproachもOracleもSQL Serverも）
数千件以上になったら、ExcelよりAccessだね。
ACCESS2000の分かりやすい本
http://pc.2ch.sc/test/read.cgi/bsoft/994154155/l50
配下の県支店の営業分析支援として大量の顧客データをクエリーとかでブン回しています。
一番件数が多いとき一つのテーブルに60万件ぐらいインポートします。
高スペック・大容量のＰＣが必要です。
一つのテーブルに６０万件って、あんたねぇ。
インポート元をどーにかした方がよろしいかと。
いったいどんなデータだ？
基幹システム（IBM）から出力された顧客台帳（契約額）。(*.txt)
県別にテーブルを分ける方が一つ一つの処理が早いのは分かるが、
同じことを8県分繰り返すのも単調で・・・
あっ、もちろん一回クロス集計とか走らせると、その間は別の仕事してますよ。
エクセルの方が、いつも使っているし、便利なんだけど
会社の上司が変にソートとかの操作をして、データを崩しちゃうんだ。
アクセスができればいいといつも思う。
ｱｸｾｽとか言う前にデータ管理をしっかりしなきゃ。
データを崩しちゃうんだって何だよ。ちょっと笑っちゃいます。
>一つのテーブルに60万件
EXCEL2000までは６０万行も使えないよ。ＸＰ？
60万件はACCESSのことですよ。
インポートとかテーブルと書いているので分かってくれたのか思いました。
それにEXCELの話だったらテーブルではなくSHEETでは？
はい、確かEXCEL97（2000も？）までは6万何千件ですな。
実務上、EXCELでは何百行しか使うことはないです。私の場合。
アクセスは、データがおかしくなることが少ないと雑誌で
読んだのですが、違うんですか?
ちなみに、データを崩すというのは、ソートをある列しかかけず
行がｸﾞﾁｬｸﾞﾁｬになるケースです。
まあ、元データのBackupをちゃんと保管しない自分が
悪いんですけどね。
買ってくれるかどうかが問題だけど。
何か根本的勘違いをしとるようだが、AccessだろうがExcelだろうが
ﾚｺｰﾄﾞ単位の集まりを表現する場合はテーブルが一般的。Sheetが云々って
論議はVBAの範囲だけでやりなされ。
>38
Accessでデータがおかしくなるって漠然としすぎてわからないし、そういう
バグ報告もない。多分、排他制御っつーかJetの仕組みもわからない馬鹿が、
データ壊しただけだろう。
確認も勉強もせず、ただ「Accessはデータ壊れるんだぜー」なんて言ってる
お前のがよっぽど使えねーよ。
>39
AccessとOracleを比べるんじゃないっての。適材適所がわからん人間だな。
まさかoracle単体で運営できるとか勘違いしてないだろーね？フロントに
Access使ってるケースって結構あるのよ？
どっかの雑誌でカジった程度の書きこみするんじゃねー。
つーか、漏れが場違いみたいだ。ごめん、逝ってくる。
まぁまぁ、この場のレベルを鑑みて・・マターリとしましょうよ。
そうすか、エクセルでもテーブルといったりするのですね。勉強になります。
ﾊｧ?
行列とレコードの違いが分ってないと思われ。
お前、頭悪いだろ。
「逝ってくる。」と言ったなら早いとこ消えな、ヴァカめ。
そういうことは、Access使うと悩まなくてすむ。
RDBでは、レコード単位でしかソートできないから。
ACCESSのソートで複数の優先順位はどの様にして設定するのですか？
ご質問のように、優先順位をつける場合は、クエリをSQLビューに切り替えて、
「OrderBy」句を使う。
例）最優先列：部署番号、次に優先する列：社員番号
OrderBy 部署番号,社員番号;
こんな感じ。（手元に実行環境がないので、検証してません）
上の「OrderBy」句っていうのが、SQL言語というやつで、単純な言語なのに
柔軟な抽出、集計ができる。ISOや日本のJISの規格にもなっている。
SQL本は、大型書店のデータベースのコーナー行くと必ずあるよ。
なぜに、わざわざSQLビューに切り替える必要がある？
SQLになれちゃったから、デザインビューよくわからない。
>>48どうやるの？
部署番号,社員番号で並び替えの優先順位を付けるなら、
グリッドに、部署番号,社員番号を落として、並び替えの行に「昇順/降順」をそれぞれ指定すればいいだけ。
データシートの表示列順が入れ替わるのが嫌なら...
データシートビューで列をD&Dで順序を差し替えて保存すればいい。
または、デザインビューで並び替え用に部署番号,社員番号をあえて追加。
同列の並び替えの行に「昇順/降順」をそれぞれ指定し、表示のチェックボックスをオフ。
>同列の並び替えの行に「昇順/降順」をそれぞれ指定し、表示のチェックボックスをオフ。
なるほど。
これによって、作成されるSQL文はたぶん同じになるんだろうね。
歯がゆい思いをしたことあったよ。
データベースのソフトしか扱った事しかなく、表計算ソフトもレコード
として、単純にソートするもんだと思ってたよ。
エクセルは、糞だと当時は、思っていたが、アクセスでは、エクセル
のように、テーブルの項目の文字のサイズを縮小したり、色を着けた
りできないので、両方使いこなせれば、グッドだね。
わかりやすい。今やってみたらうまくいきました。thanks!
私もエクセルの勉強しはじめのころ、ソレやったよ〜
ツールバーのソートボタンを使ってみる練習してたとき。
任意の列を（全て）選択してからボタンを押すんだなー
って最初は勘違いするよね…。
Excel2002では、「全部の列じゃないけどいいのかい」っていう警告メッセージが出たはず。
決められた書式に合わせなくちゃ行けない場合は、Excelの出番だね。
基幹システムでアイテム・月別のサマリーファイルを作ってもらって、
それをインポートすれば良いのでは？ 契約単位の細かい明細が必要
ならしょうがないかな。システム部門に相談してみることだ。
単純に範囲指定が正しく無いから、おかしくなるのでは？
「エクセルは、糞」ってあんたの使い方が糞なんだよ。
エクセルに初めて触れた当時の話だよ！５，６年前の話しな。
今は、もちろん糞とは、思ってないよ。むしろ、重宝してる。
ご親切にありがとさん。
ちなみにレコードごとソートは、表の左上をクリック（シート全体選択）し
データ→並び替えをクリック。ソートの基準は、どれにするか選択画面
が出てくる。列を指定する。ＯＫの手順だ。
良く出来ました。
報告するよろし。
40の書き込み見たくないので煽る発言は、辞めてくれ。
１日１，２レスくらいのマターリで行きまひょ。
EXCELのVLOOKUPとかいう関数よりもクエリーで結合線引っ張る方が楽。
こんな使い方しかしていません。素人なもので。
クエリーで結合線引っぱる・・
どやんの？
挙げ足取り？
マウスでテーブル間に結合線を設定することじゃないの？
あ〜俺も表現下手なんで挙げ足取られそうだよ。
>>63
素人も玄人？も使い方は一緒。
必要なデータをどう切り取り、表現するかの問題だけだよ。
手段が目的にならないように気をつけましょう。
多分、クエリ作る画面とか、リレーション設定の画面で、
テーブル間をつなぐことでないの？
データの抽出って表現からして、コレかと。
>63
抽出って、エクスポートとかしてる？だったら、必ずクエリを
エクスポートするように心がけないと、データの並びが違う場合が
出てくるから注意したいですね。
テーブル間をつなぐことですよ・・
例えば、Aというテーブルにお得意先の会社はコードで、Bというテーブルには会社名で。そんな感じの時。
>>66
抽出の方法も色々あるのでしょうけど、フィルタを使って対象データだけに絞った後、EXCELに出力することが多いです。
もちろん、Bのテーブルには会社コードと会社名が格納されていて、A-B間を会社コードでつなぎます。（こんな表現でいいかな…）
>>65、>>66さんには言うまでもないことですが、一応補足します。
ＥＸＥＬとの違いが分かると思うよ
違いが分かったら、リレーショナルＤＢに出来てカード型ＤＢ出来ない事を考えるんだ
その中でやってみたい事があれば、そこから勉強すれば良いんじゃないかな？
どっちのＤＢ構築で一番重要なのはＤＢ設計だから
ここの部分を把握せずに作り始めると、最後に無く結果になるかもよ
正規化ってやつね。
安くはないけど、圧倒的に簡単だよ
表計算との違い？
表計算は自動保存もするようになったけど、
基本的にデータを全部開いて処理するのが表計算、
一つのデータをいろんなファイルから入力できるのがDB
感じなのかな？
ファイルメーカーのほうが簡単だよ。
クエリのデザインビューで結合線を引くのと
「リレーションレイアウト画面」で結合線を引くのとどう違うの？
後者の場合「∞⇔１」（∞は主キー）のマークが出るんだけど
クエリのデザインビューでは出ないよね。
自分の仕事用にいくつか作って、だいぶ楽になった。
でも、Access+SQLServer(adp) はむずぃ
実験でいろいろ試してるけど、一つ壁を超えてもすぐまた
大きな壁に・・・。Access単体ほどに初心者にやさしい
情報もなさげなのできちぃ〜
リレーションの画面では「参照整合性」が設定できる。
連鎖更新、連鎖削除も設定可能。
「∞⇔１」は参照整合性を設定してある場合のみ表示される。
後、2000とかなら、リレーション張っておけば、サブデータシートとかも使えるし、
いろいろ便利。
エクセルでやると長い文章が打ち込めないのが理由です
蔵書整理をアクセスでやるとエクセルでやるのにくらべて
どのような利点がありますか？
保存する必要が無い。
どうせ読み直すことなんて無いでしょ？あと図書館もフル活用すべし。
>エクセルでやると長い文章が打ち込めないのが理由です
整理するのに長文入力って。。。あらすじでも書くの？
それに要する時間で他の本を読んだ方が人生有意義のような。
御愁傷様
はい、必要ありません。
買って読んでは売るというスタイルで、厳選された１００冊程度が残るのみ。
二回読まない本は置くだけ無駄というか、何が必要で何が不要かわからなくなる。
残すか売るかは即断即決、これ日本人ビジネスマンに最も欠けていることだよね。
凄いね が、ここはあんたの決断力自慢スレではない
早く図書館でも行け、人生の無駄だ
即断即決は自慢じゃ無くて、後から判断すると既に本の内容を忘れてしまう。
それでまた読んでしまう（一部だけど）、この作業が無駄というか勿体無い。
仕事のスタイルがそうなんで癖になってしまってる。
実際に蔵書管理ってどんなことをしているんだろう？
ＣＤ管理とかは借りてきたの録音する場合、ＭＤにタイトルや曲名を記入
するから、それをＰＣ使って入力・印刷さらにリストも同時にできあがる
っていうイメージが思い浮かぶけど。
>>87
これから、パチンコでもしに行ってくるよ。
勝ったら飲みに行こうぜ！
70はマスターした、と言う。
85は挫折した。
どっち？
「あんた、表計算ソフトのようなもの」っていう意識持っていないか？
DBは悪いが、まったく違うソフトだぞ。
出直してこい。
出てこいって言うだけでも酷な話だよ。
上司に「こういうソフトを作ってくれ」と言われて作り始めたはいいが、テーブル設計がうまくいかなくてスパゲッティになってしまうという罠
蔵書管理は正にAccessの方が向いている分野かと思われ。
ExcelでなくAccessで行う一番のメリットは、データ抽出が容易になること。
Excelでも簡単なフィルタやソートは付いてるけど、Accessの方が断然強力。
グループ集計してグループ毎の小計と全体の合計を出すという処理もAccessの方が得意。
逆にExcelの方が向いてる分野は、行をまたがった計算が多い場合。
例えば家計簿とか現金出納帳の残高計算。あれをAccessで作る方法を教えてくれ、
しかもマクロもVBAもわからないから使わないでくれ、なんて言われたら氏ぬ。
要は累計計算のことか？
Accessには累計計算の直接的な機能は無いが、選択クエリーで対応できる。
マクロもVBAも必要ではないから氏ななくてもいいぞ。
ただし、対象のテーブルに上下を判別できるフィールドが存在していることが条件
例）
テーブル名：家計簿
フィールド：ID(オートナンバー),入金,出金
クエリの演算式は下記のとおり。
残高: DSum("[入金]-[支出]","家計簿","ID<=" & [ID])
その残高計算の式、理解できるやつを初心者とはイワン
それに、それじゃぁ件数が増加すると劇遅になるぞ（ｗ
残高を「簡単かつ高速」に表示させるなら、レポートで表示だ。
よく覚えておくように（ｗ
補足サンクス。
そーか、レポートの「集計実行」プロパティ忘れてたよ。
でも前述の式、単票フォームの非連結テキストボックスに利用するなら意味あるかも。
それに家計簿程度のデータ量ならクエリーでDSumを使ってもそれほどストレス感じないだろう。
といってみる。
100〜のスレッドの続きを読む